OpenXTalk Forums

Devawriter Pro is a program for digitisation of historical Indic languages with a primary focus on Sanskrit currently deployed in about 50 universities worldwide, as well as being used by various private individuals and a Hindu monastery in Hawaii) that has been developed with LiveCode for 14 years and is currently in its 5th system development lifecycle.

I should very much like to transfer my code-base to OXT Lite both for development and for running off standalones for distribution.

To that end I have made a modified stack in OXT Lite to run off standalones for Macintosh, Windows 32 and 64 bit, Linux 32 and 64 bit.

My first attempt at opening my OXT stack, having modified it and saved it was met with this:
- -
The reason for this is entirely my own fault.

BUT that warning should NOT talk about LiveCode, it should talk about OpenXTalk.

(crosses fingers, expecting things 'not' to break, but you never know)

OK: got the stack reopened in OXT Lite . . .

[That last glitch was my own fault to do with a name conflict that I really should have seen coming.]
- - - -
Mind you what with "over loaded" signals and "HTTP errors" everything round these parts seems an uphill struggle.

The standalone builder chewed its way through those 5 standalones without any obvious hitches at all.

First comparison: (Mac builds) LiveCode build on the left, OXT Lite build on the right:
- -
OXT Lite build fails to display a JPEG image correctly.
- -
Confirmed by second comparison.

I don't know why this is happening: I ran up a stack that looks like this:
- -
And built a Mac standalone, and the JPEG displayed perfectly.

Similarly I built a stack containing the single image the OXT Lite Mac Build of Devawriter displayed incorrectly, and built a Mac standalone from that: and the image displayed perfectly:
- -
But, obviously until that problem has been sorted out I cannot consider using OXT Lite to build my Devawriter.

richmond62 wrote: ↑Sat Apr 27, 2024 6:31 pm ...BUT that warning should NOT talk about LiveCode, it should talk about OpenXTalk.

I know why that shows "livecode" in the crash error, rather than the openxtalk name. That's because this seems to be the engine that's crashed. The mac version of the engine gets it's name from the compiled name in xCode - and does need changing in the xcode project when we recompile, so whatever is causing that is original untouched code in the engine.

As you know, I've not been able to recompile the mac engine, so it still has the LC name instead of OXT.

richmond62 wrote: ↑Sat Apr 27, 2024 8:23 pm I don't know why this is happening...

Me neither. That is weird. The fact you can copy and paste that image into a stack, then build that in OXT - and the image shows up.

It makes me wonder, if you are cutting and pasting it, it becomes an embedded image that builds okay.

I wonder, is the image's 'source' / filename - is it being loaded in from file, or normally an embedded image within the stack? I'm wondering if there's something that references a livecode path that isn't there in the oxt build. Or, perhaps in the standalone settings, that image isn't being set to be included?

Not sure what could cause that.

What happens if you copy that image to a new stack, delete the one that won't build in devawriter, and paste that one back in from your new stack? Does it show in the built version then?

I don't know what it doesn't like about that image, but as the stack format itself hasn't changed, something else you can try:

In finder, duplicate a working copy of your livecode stack version.
Rename this duplicate with an oxtstack file extension.
Open that in oxt lite and see if it'll build.
I'm wondering if there's something about that image it doesn't like when it's trying to resave everything through the IDE, BUT - this is just an out-there guess, If it's doing that, I'm not exactly sure why.

It's more confusing because all your other images are there. I'm assuming those buttons are also pictures in the OXT Built version?

Is that shaded red background on the title screen, the same file used on the card it won't display on?
If it's different, then there might be something weird going on with that file it doesn't like (again, not sure what), but if they are the same background, you could use either use a shared group with the background in which it repeats across multiple cards, or you could try an image swap method such as:
That would replace the binary image data of the file that won't load, with binary image data from the image that does. Why this would only happen in oxt, I don't know.

Conversely, here's another thing you can try - which will check if there's any corruption involving that image. The oxt stack that you saved - which seems to build incorrectly: what about if you renamed this file from .oxtstack to .livecode, open that in LCC and see if that will build correctly? If it has the same problem of the missing background, then I'm wondering if it's something in the oxt stack resave process. It might not be though, and the simple act of resaving the stack might be making something get stuck on that image.

I'm just going to try some build tests here as well, to see if I can duplicate the issue.

Here's what I've tried so far:
Create a stack in LCC 9.6.3, with a PNG and JPG variant of a test image (your red background).
I created this in LCC as your devawriter stack has been, just to keep the process the same (however simplified this test is). Then I built a mac standalone from this called "image-test" - and renamed the folder so I know it's the LCC one.

Next, I opened the stack in OXT Lite, and built the standalone again for the mac. (repeating what I'd just done in LCC). Again - I renamed the folder so I know it's the OXT one.

Now running both of these programs on the mac, you can see they both include the PNG and JPG images - the LCC one on the left, the OXT one on the right: So I'm still no nearer to finding why your bkgnd image does not appear
At the moment, I'm either going with the theory that it's either a path to an image it can't find, or some type of image corruption on that file when it's resaved (but specific to your stack). - But, this is only a theory.
If you replace that problem image in your stack with a working one, does it then build correctly in OXT lite?

Right, just back from the church, it being Orthodox Palm Sunday, and my religious beliefs being a bit like palm leaves: blowing back and forth.

So: the intelligent thing seems to be to have a look at the offending card in OXT Lite and see if that JPEG is as wonky as it is in the MacOS build:
- -
IDE on the left: MacOS build on the right.

So obviously something is going "off" during the build.

Exporting the offending image as a JPEG, converting it to a PNG and importing that renders the thing satisfactorily:
- -
Although at a hell of a 'price' as the JPEG file is sized 470 KB, and the PNG 1.6 MB.

Replacing the image with a GIF at 573 KB also renders satisfactorily.

So: because I am bonkers, I replaced the image with the JPEG I had exported and:
- -
Perhaps that is why I go to church; a slight feeling that some things in life are not quite as logical as one might expect them to be.

Now: of course, I am going to have to track my way through the 50+ cards and the thousands of images (Yes, every button is NOT a button, it is an image) in a standalone to see which ones 'Do' and which one's 'DON'T'.

https://youtu.be/JY3pkagVP64

And so it continues, I am afraid: this time things appear more mysterious:
- -
IDE on the left, standalone on the right.

The image that fails to render is a PNG image that is partly transparent:
- -
And what is extremely bizarre is that same image renders perfectly correctly on the preceding card, and thcard after this one.

This means that there is no consistency in predicting how images will be rendered in a standalone, and no guarantee that if one replaces a non-rendering image that it will render satisfactorily the next time.

For me this situation makes transferring my Devawriter to OXT completely unworkable at this time.

richmond62 wrote: ↑Sun Apr 28, 2024 10:04 am ... that same image renders perfectly correctly on the preceding card, and the card after this one.

Is it actually the same image, as in - an image in a shared group, with it's "behave like a background" checkbox set in the inspector? - or, is it a duplicate of an imported image?
If it's a duplicated image (with a different ID), then I'm wondering if some of these images are corrupt.

richmond62 wrote: ↑Sun Apr 28, 2024 10:04 am This means that there is no consistency in predicting how images will be rendered in a standalone, and no guarantee that if one replaces a non-rendering image that it will render satisfactorily the next time.

For the images you've replaced, if you repeat the build process - do they then show consistently?

So here's a weird question.
If you were to resave the stack in LCC, close it fully (Quit LCC) then reopen your resaved copy, does that build okay?
I'm wondering if the act of resaving the stack is doing something.
I'd like to do these tests in LCC first, to rule that out.

Oh, you can be sure I have played all those 'funny tricks' before messing around with replacement images, to no avail.

The thing that is really mysterious and annoying is the inconsistency with which images and which types of images render incorrectly and when they do and when they don't.

I have just spend 2 hours b*ggering about with images and ending up no wiser, and am now about to stump off in a fairly filthy mood for a glass of beer and a pipe in the garden: where, probably, I will calm down and after lunch have another 'stab' at things.

I wish I knew why it was doing that too.
As you say, there seems to be no logical pattern to it.

The only other things I can think of are things I'm sure you've already checked. Making sure the jpegs aren't cmyk and are rgb. Making sure they are 72dpi / 96dpi - but at least nothing like 300 dpi, as I know this can occasionally cause the rendering to run out of memory. (Not the memory in your computer, but the memory the engine & standalone allocates to the rendering process).

I understand devawriter is a lot of years worth of your work, so of course I trust you are working on a sacrificial copy.
I know you'd not want to pass me a copy of your stack, as it's your personal property - that's why I've not offered to build it myself here.
I just would like to rule out corrupt images, so if you can send me (probably zipped) an original copy of the problem image to look at, just so I can inspect that fully.

Devawriter is open source, so if you give me a place I can upload my source stack so that thou (and preferably only thou) can play with it, I'll do that.

I've just run off a build using OXT Lite 1.03, and opened the standalone.
(The various screenshots move about a bit, just because of me moving the window about between screenshots).
Rather than me uploading loads and loads of screenshots here, I thought the best way to show you what I encountered was the following contact sheet - all the thumbnails of the screenshots for quick viewing: As you can see, it all worked flawlessly as far as I can tell.
No missing images I think.

The only thing I could critique (that's the wrong word really) - I mean, the thing that I noticed, would be the bundle identifier was filled out incorrectly. That initially caused no background image for me on the first card. So I replaced "com..dwpro" with "com.richmond.dwpro" and then it built again and it ran fine - as per the above screenshots. I wonder if that's the problem?
If not, I'd next wonder what version of MacOS were you running OXT / LCC on when you built your standalone?

MacOS 12. whatever, OXT Lite 1.03, LC 963.

The images display properly in the stack in OXT Lite.

However, in a Mac standalone made with OXT Lite, the images I mentioned above go black.

Those screenshots are all taken from a fresh standalone, built with OXT Lite 1.03. (Built on MacOS 10.9 Mavericks), so all seems to be working here as intended.

Just to confirm, I didn't have to resave any images or anything like that. I just went into standalone options, corrected the bundle identifier, set Mac OS as the destination platform, then I chose 'Save as Standalone..."

These kind of errors are the worst, as not being able to pin down what's at fault is frustrating - because it's then very hard to know what to fix.

richmond62 wrote: ↑Sun Apr 28, 2024 1:32 pm MacOS 12. whatever, OXT Lite 1.03, LC 963.

I hate to sound like a broken record, but there's your problem I think.
You know I don't put 100% faith in anything running as intended above MacOS 11 - but that's only a theory (an educated guess, having looked at the 9.6.3 engine?). Call me cynical, but you probably knew I'd suggest that.

I'm hoping the fix instead is simply the bundle identifier I mention above, but if not, I'd try building this while running under MacOS 11 (or lower), or even building this on Linux for MacOS.

While I'm going on about the bundle identifier, you might have this filled out - I don't know if this info is coming across with the stack(?), but using the "????" "Signature" - (I'm assuming they mean creatorcode in old terminology) will yield a generic white MacOS application icon. You may already have set this as I say, and I'm sure you are aware of that


I'll pop the built standalone back into that dropbox folder I shared with you.
If you run that standalone I uploaded in MacOS 12 and notice missing images, then I think it's fair to summise that it's either a MacOS version issue, or something specific to your mac.
If you can test my standalone on an older mac (MacOS 10.9 through to MacOS 11), and see if that works?

I'm just working through a process of elimination at the moment, but OXT lite seems to be able to build it without any error at this end.
If I get a chance tomorrow, I'll test it on MacOS 10.15.5 and see how it works there.

Thank you very much for taking such a lot of trouble.

The standalones do have their own icon (I did not send you that: sorry).

I will do several things tomorrow:

1. I will run off a Mac standalone from OXT Lite on my MacOS 14 machine at work.

2. Try your build on that machine as well.
- -
I have just uploaded the Mac and the Windows icons to your DropBox.


*AND, here's a really bonkers situation:

Last time I opened my OXT Lite Mac standalone the images were wrong on what you might call card 'y', BUT this time the images there were OK, but they were wonky on card 'z': what a doctor or a psychiatrist would call "shifting syndrome".