LiveCode Forums.

Hi. I created one button with and in the software works this script but in the standalone software not working, the Inclusions is automatic. Why not insert the text into field in standalone version?

Why do I feel that having a variable and a field with the same name is unwise?

Hi. I created one button with
-------------------------------
ask "Age"
put it into field "age"
-------------------------------
and in the software works this script but in the standalone software not working, the Inclusions is automatic. Why not insert the text into field in standalone version?

I tested this question from early Metacard versions to Lc 9.x, on 'nix, and was unable to reproduce the issue, so you would need to include more information for the regulars here, such as :
1. Operating system(s) tested on
2. LiveCode/Xavvi/Creator (or whatever they are calling it now) Version
3. Any other code that may be affecting the outcome.

Just to make sure the minimum testing was fulfilled, you had 1 stack with 1 button with 1 field , and not just 1 stack with 1 button, missing a field, correct?

Why do I feel that having a variable and a field with the same name is unwise?

This would have no impact whatsoever. First of all the variable being pulled is the "it" variable, which is coming from an ask dialog, so it isn't going into another variable named "age", that is the name of the ask dialog in this case.

The field name is post the field object in code, not to mention you could literally name every object the same name in an example such as this for the same reason. As an example:

"age" // variable
Stack "age" // stack
card "age" // card
button "age" // button
field "age" // field

If your program were to grow larger, and you had several field controls (label and text are both field objects) then you might have an issue, if you did not include other identifiers { such as id, layer number, etc }, but not an issue confusing a variable with either of the fields.

@Bogs.

Long time no see!

The OP would have seen an error if there was no such field "age"

@Seal29.

Yep, that code is rock solid, and Bogs' point about giving the environment data is pertinent

But have you tried making the standalone with manual inclusions? Both the answer and ask dialogs are required to be, er, included, and there have been reports that the automatic gadget is unstable. I was bitten by that years ago, and so always include by hand. I have not seen such reports in quite a while, so do report back with all the info that Bogs mentioned.

Craig

Sorry this si my fault.
After checking the program, but before compiling it,somehow another letter e was added to the name of the field so field "agee"
Sorry. I almost went crazy when I noticed.

SEAL29 wrote: ↑

Sun Oct 27, 2024 3:42 pm

Sorry this si my fault.
After checking the program, but before compiling it,somehow another letter e was added to the name of the field so field "agee"
Sorry. I almost went crazy when I noticed.

Good catch. The bright side of your mistake is that it brought Bogs back.

Nice to see you again Bogs.

dunbarx wrote: ↑

Sun Oct 27, 2024 2:13 pm

@Bogs.

Long time no see!

The OP would have seen an error if there was no such field "age"
~sic~
Craig

Happy to see you still jumping right in, it was ever one of the highlights of being a member here

In the IDE I agree with you, however, if you've tested in the IDE and it worked, I can see where not seeing the expected result in the standalone would be confusing, since you will get no error there (without your own extensive error checking code in the program), it would just fail silently.

I don't know of anyone who by default tests for the existence of an object they are sure is in the program heh, but there may be someone that thorough

In this case, a typo changed the expected object to a completely different object in the exe, where it failed silently. Glad you found it SEAL29.

Glad as well that all is, er, well.

But that means that the name of the field was changed sometime in the IDE, not ever run there, and then the standalone was built.

Could happen, of course.

Craig

Exactly

Well, many a slip twixt cup and lip. To be fair to the OP, I think we can all honestly say we have made similar mistakes "once or twice".

Good to see you here, Bogs.

Hey bogs!

I had a question asked of me just this weekend "What are these manuals doing here?"

richmond62 wrote: ↑

Sun Oct 27, 2024 9:06 pm

Well, many a slip twixt cup and lip. To be fair to the OP, I think we can all honestly say we have made similar mistakes "once or twice".

In my case, so often it has become a hobby

FourthWorld wrote: ↑

Mon Oct 28, 2024 12:25 am

Good to see you here, Bogs.

Same Richard, I often miss our extended, deep, sometimes humorous, sometimes philosophical discussions.

SparkOut wrote: ↑

Mon Oct 28, 2024 8:56 am

Hey bogs!

I had a question asked of me just this weekend "What are these manuals doing here?"

LOL I really could not thank you enough for the major gift 3 was to me, it was helpful in delving further into the rifts between releases.

Bogs.

Did you mean the fits between releases?

craig

No, I mean literal rifts, both internally and visually, between how the different IDEs were put together, performed, etc. between Mc 2.x to Lc 6.x/7.x. Sometimes it is easy to see why certain changes were made, sometimes not so much.