Application Build Number

[marksmithhfx]

It's also interesting that your first attempt failed and the second one didn't, which is what I saw too.

Deep within the heart of livecode their lurks a mystery and it's our job to discover it

My theory, that does not make a whole lot of sense, is I changed the default version number and that triggered a change in the internal settings of LC. Elanor used 1.2.3 so she had changed the setting. Did you by any chance change the version number as well? Probably a silly idea but certainly difficult to fathom an alternative.

One more to add to the "here's how it works folks. Don't ask too many questions" pile. (I'm being silly, of course).

Cheers,
Mark

[jacque]

No, I used an existing client stack which was already open and just queried its setting from the message box. When I opened the same stack in LC 9.6 it worked. I flipped back over to 9.6.1 and asked again (the stack was still open and running) and it gave me a response.

I'm sticking with my theory that the wrong stack was being queried from the message box the first time -- but that doesn't explain your results. I'm stumped. Whatever it is, it seems like the stack needs to be poked before it responds.

Edit: In LC 9.6.1 I have had many, many incidences where the message box does not know which stack to operate on even though its object field indicates the correct one. I have clicked on the stack to force it forward (though it already was,) specifically set the defaultstack in the message box, re-selected the stack in the object field, and done I can't remember what all, and the message box commands are still sent to the wrong stack. These are topstacks, not modal or modeless, and should be receiving message box queries. I have no idea what triggers the behavior.

[marksmithhfx]

I'm sticking with my theory that the wrong stack was being queried from the message box the first time -- but that doesn't explain your results. I'm stumped. Whatever it is, it seems like the stack needs to be poked before it responds.

I only once tried it from the message box, with no luck. But I'm not a pro at using that tool so it could easily be something I wasn't doing correctly, so not feeling confident about it I reverted back to doing it from inside my stack in the "on SavingMobileStandalone". As you indicated, it could have well been a problem with that procedure, but I hard-coded in the value and was able to read it at the other end so I don't think the procedure was the cause (and now we know the cps is not being stripped out -- I think!!).

So we arrived at a much simpler solution. A serendipitous outcome I can live with

Mark

[marksmithhfx]

I'm sticking with my theory that the wrong stack was being queried from the message box the first time -- but that doesn't explain your results. I'm stumped. Whatever it is, it seems like the stack needs to be poked before it responds.

Confirmed. Elanor did some testing and discovered that if you don't change the default version number, the cRevStandaloneSettings["ios,bundle version"] property does not exist. It only gets created when you change the number from 1.0.0 to something else (or maybe even to itself, I did not try) which is why, when I changed it to 1.2.3. it started working and when I changed it back to 1.0.0 it still worked. (her exact words, which are probably clearer than mine: "1.0.0 is the value that appears if the cRevStandaloneSettings["ios,bundle version"] is empty". Which is why, without actually changing the value I did not see anything. This may have accounted for what happened in your case as well?

She also recommended the method of storing it as a custom property in the stack, as I was doing, and not reading it directly as in the future that information could get stripped from the stack. I think that was the conclusion from previous comments on here as well...

my approach, taken from looking around and doing a bit of research was:

Code: Select all

on SavingMobileStandalone
   put the cRevStandaloneSettings["ios,bundle version"] of this stack into tVersion
   -- put tVersion into msg
   set the cAppVersion of this stack to tVersion
   save this stack -- necessary step as this is happening during the build
end SavingMobileStandalone

This works fine. Sometimes these processes of discovery can get quite involved
Mark

[jacque]

That's very good info to know, thanks for posting it. In my case the stack already had a version number, so something else was going on. I also save the version in a custom property like you're doing but often forget to update it before doing a build, so I think I'll adopt your method now. That should save me some swearing and rebuilds.