LiveCode Forums.

One option would be to use a shared group that is placed on all cards. When the object is hidden it could be placed into this inventory group. When you unhide the item you would also need to move it out of the group. The way the shared group works would allow the image to be available on all cards.

You could iterate over the keys at the first level and get the size of each sub-array via encoding. Then you could do the same for the largest key at the next level and so on (if size would point to a possible issue). Another option is to just use the tree widget to display the data and you can brow...

Unless you have the stack password protected, I would use a tool to export the scripts of the stack out to files every time you make a commit on the binary. That would provide versioning of the scripts where you could easily see what changed over time.

Forums for Create:
https://discourse.livecode.com/

The forum was established for the Xavvi backers who were granted early access to test Create very early in development. I believe early access was also sold. The forum was initially for discussion of the new product and as a way for users to report bugs. From the LC bug comments I’m pretty sure they...

Heather replied on the list that if you sign up for the webinar then you would be able to view a replay.

This was maddening. One can set a custom prop to anything one wants. But one cannot set a custom prop to the contents of a variable with the same name: snip A new custom prop, named with the value of the variable itself , is created, and contains (what else?) the value of the variable. At least LC ...

You could also layer another native control over the chart. I’ve seen examples before that used another browser widget with transparent background to overlay something over another native control. I’ll see if I can locate any of those examples. EDIT: Here's a link to the post... https://forums.livec...

It points up to the control. I was wondering if it should loop back and point down to the control (or even just back to the message path line).

OK, I think we're on the same page... just saying the same thing differently ;) That being said... how would you like to see that inset graph changed? the latest version seems fine to me, and not really saying anything different from what you say. I agree, the flow for behaviors is a bit complicate...

My comments about the message path are a paraphrase from the documentation: A before handler allows developers to produce behavior scripts which can handle messages sent to a control without having any effect on the message path, unlike front and back scripts. So, yes, the message does travel a slig...

Can you please elaborate on That side route should be “not in” but before/after still will get called. I'm not sure I understand this? I now realise the right side-arm ('Handled in object 1') is wrong and should be removed, not sure if that's what you mean? Yes the 'before' handler in the behaviour...

Let me reply with code. Consider the following code that will be in each of 3 buttons and the card: before mouseup put "before mouseup" && short name of me && short name of this me & lf after fld "Log" pass mouseup end mouseup on mouseup put "on mouseup" && short name of me && short name of this me ...

Hi Brian, What do you think of having this as an inset graph to accompany the main graph? Obviously open to corrections... I like the idea. I actually threw a stack together last night to test/verify flow. That side route should be “not in” but before/after still will get called. If you pass in the...

I like having them in the muted color like your last one. I think an info box at the bottom with some of the caveats that should be considered would work. Behaviors support the before/after control structures which allows developers to produce behavior scripts which can handle messages sent to a con...