LiveCode Forums.

Posted: **Tue Nov 03, 2015 9:44 am**

Hi

This is not the first time I have encountered this, but this time I have a working example where it has been captured.

The fault is where an object has the right code but it does not behave as it should. A have found a cut/paste of the object fixes it. I do not understand and it is very annoying when it happens. Has anyone else seen this?

Scenario
I have several buttons. All basically identical code for the button image handlers. It has two images attached as icons to highlited and unhighlited. It toggles and works correctly. It has routines to allow calls to the button to toggle it. The calls do not toggle it. If I do a mouse press on the card, where there is no handler, the button updates. Al the other buttons work properly - but not this one!!
I cut/paste the button - doing NOTHING else. NOW IT WORKS PERFECTLY. ARGH!!

I have the code before and after fixing the bug. Visibly, there is nothing different but somehow it is now working. The messages were being passed to the object (I proved this by placing 'answer' within the button), it just was not switching the image as it should until triggered by a mouse click elsewhere.

Has anyone else seen this kind of behaviour?
Matt

Posted: **Tue Nov 03, 2015 6:10 pm**

Hi Matt,

in the more than 15 years I haven been working with LC and its ancestors, I very seldom experienced
corrupt objects, maybe 2 or 3 times, but it was always a FIELD.

Maybe you can show us your script to exclude that as a source of the error?

Best

Klaus

Posted: **Tue Nov 03, 2015 6:19 pm**

I am surprised (and pleased) to here how stable your experience has been. I have had entire stacks go corrupt where I have had to cut all of the object out of the stack and paste them into another stack to save them. I have had this weird issue a couple of times before too. This was the first time I caught it in the act and been able to capture a corrupted stack (or object) and a fixed one where the only difference was the cut / paste. The other weird things about this 'bug' was if I clicked the button a number of times it started working then the calls to it would also work perfectly as well. All very strange.

I would be very surprised is there is a bug in the code as there is nothing really in the code.
Also, cut and paste would not magically just fix the code however, I have been wrong before so here is the code

Code: Select all

function readControl
   return the highlight of me 
end readControl

on setValue
   set the cPublicOrPrivate of this stack to "Private"
end setValue

on unsetValue
   set the cPublicOrPrivate of this stack to empty
end unsetValue

on resetControl 
  unsetcontrol
end resetControl

command SetControl
   call unsetControl of button "btn_public"      
   call unsetControl of button "btn_soletrader"     
   call setcontrol of button "btn_yes"   
   
   set the highlite of me to true   
   setValue
end SetControl

command unsetControl
   set the highlite of me to false
   unsetValue
end unsetControl

on mouseup
   if readControl() = false then
      setControl
   end if
   CheckToSeeIfSubmitCanBeEnabled
end mouseup

To fix it, I just selected the button, did cut and paste and everything worked perfectly. That was damn weird.

I would love learn what I have done wrong so please point it out if I have made a mistake so I can improve.

Posted: **Wed Nov 04, 2015 12:03 am**

Hi,

independent of the platform I have regularly similar experiences with non-stable LC versions (dp and early rc versions), but (as Klaus) nearly never had this with stable LC versions.

When looking into logs I saw memory segmentation faults (LC's culprit) but also crazy conflicts that came from new (as always nearly undocumented) MacOS/iOS behaviour.

Did you have such bad experiences also with combinations of stable MacOS/iOS and LC?

hh

Posted: **Wed Nov 04, 2015 12:28 am**

I only work on Stable platform.
I am using the MacOS Livecode Indy 7.1

Posted: **Wed Nov 04, 2015 1:44 am**

So this looks like a perfect candidate for a bug report ( http://quality.runrev.com ).
Isn't it Klaus?

Posted: **Wed Nov 04, 2015 1:32 pm**

[-hh] wrote:Isn't it Klaus?

Yes, it isn't it!

@mvillon
This is surely not the reason for your inconvenience, but make sure to always use the official syntax,
the engine is less and less forgiving with each new release.

Put QUOTES around the "call"ed handler names:
...
call "whatever" of btn "xyz"
...
Same for "send" and "dispatch".

Posted: **Wed Nov 04, 2015 4:54 pm**

I think the problem is with the "call" command, which changes the context of the message hierarchy and will give unexpected results depending on the current state of the calling button. It would be more usual to use "send" if each button is using the same script you posted. The problem should resolve with the send command.

This kind of repeated script is a good candidate for a behavior too. You might want to try that later.

Posted: **Wed Nov 04, 2015 6:02 pm**

This kind of repeated script is a good candidate for a behavior too. You might want to try that later.

I am not sure what this means but I am not interested. Are you able to point to a resource to explain what you mean by a 'behaviour'. I am always in better ways to improve my code.

Posted: **Wed Nov 04, 2015 7:11 pm**

This may get you started: http://lessons.livecode.com/m/4071/l/69 ... a-behavior

EDIT:
And also check chapter 5.8.7 of the "User Guide" PDF, accessible via menu "Help" in the Livecode IDE!

Posted: **Wed Nov 04, 2015 7:31 pm**

See "behavior" in the dictionary (you'll have to spell it the American way, much to the chagrin of the rest of the world.)

A behavior is a sort of private backscript that can be assigned to any number of controls. Just as cards can use the script of their stack, controls will use the script of their assigned behavior. This is especially useful in situations where you have many controls that all use the same script (radio groups are a good example.) Rather than putting that script into every copy of the radio button, you just assign each one a behavior script and they will all use it. The control itself doesn't need its own script at all, just the assigned behavior. At present, the control that actually contains the behavior script must be a button, though its script can be for any type of object. The behavior button does not need to be on the same card, or visible, or otherwise used in any way; it's strictly a place for script storage.

Behaviors are very handy and will change your scripting style once you see their power. One big plus is that changes to the script only need to be done once inside the behavior button; all objects that use the behavior will immediately use the updated script as soon as it is compiled. Another advantage is that behaviors only apply to the controls to which they are assigned, which means you no longer need to check whether the "mouseup" message you're getting is coming from a control you want to respond to; if the control has a behavior, then the mouseUp message will go to the behavior script. Other mouseUp messages from non-behavior controls will pass to the card, stack, etc. normally.

Consider a group of radio buttons. You could put an identical script inside each one, as you are doing now. Any changes you want to make later will have to be copied to every radio button.

For that reason, it was common to put the script into the group and use "the target" to determine which button was clicked so the script can act on it. This gives the advantage of only having one script to edit, but adds the disadvantage that the handlers need to check the target to see if they should take action; after all, the "mouseUp" might be coming from a list field or somewhere else.

Now that we have behaviors, a single script is stored in a button somewhere in the stack or a stack in use. Each radio button in the group has no script of its own, but is assigned the behavior of the "master behavior" button. Now we have the best of both worlds: there is only one location for the script, so updating it only needs to happen in a single place, and second, a "mouseUp" (or any other message) will be sent to the behavior script first before being passed through the message hierarchy. That means the behavior script doesn't need to check where the mouseUp originated, if it received the message then it came from an appropriate source.

And there's a third advantage: any reference to "me" in the script applies to the control that has the behavior assigned. So in the example, "me" would refer to the radio button that was clicked rather than the behavior button that contains the script. Basically a behavior acts like a regular object script, only it doesn't live inside the object and it can be applied to any number of them.

Posted: **Wed Nov 04, 2015 9:15 pm**

That is brilliant. You are right when you say it will change programming style.

To date I have written a script to copy the script from my master object to the objects of interest. This is a far more mature method.

Thank you both.

Posted: **Wed Nov 04, 2015 10:52 pm**

Hi Matt,

behavior is very convenient and powerful.

One thing to be aware of is that they are assigned to a control by referencing the long ID of the button with the behavior script. Internally that translates to "button id xxx of stack "yyy""

So far so good. But if you change the name of your stack the behavior breaks and has to be assigned anew. This led me to assign the behaviors in e.g a openCard script. Then you are sure they don't break when the name of the stack changes.
(I have the habit of versioning the stack name while developing in order to be able to have two versions of the stack open at the same time)

If you are using behaviors for controls in a group you could assign the behavior on "openControl", this is sent to a group when the card opens.

If you keep this in mind there won't be unexpected, well, behaviors

Kind regards
Bernd

Posted: **Fri Nov 06, 2015 10:18 am**

@mvillion: Do you have a stack which shows the broken button which is fixed by cut/paste? If so, it would be great if you could post a bug report (http://quality.runrev.com).

Objects have internal state which script cannot see so it is possible you have found a case where this internal state gets out-of-sync with expectations. Such state does not persist so if you cut and then paste, the object's internal state gets reset.

(Cut/Copy/Paste of objects works almost identically as saving the object to disk and then reloading it - it just does it in memory).

Posted: **Fri Nov 06, 2015 11:15 am**

Hi
I have captured the event in a stack. I will be submitting it in the next day or two.

Additionally
On Indy 7.1 I also get lots of crashes. The way to trigger this is try to work with LC with a trackpad, and not a mouse. If you are not 'clean' with your drags and drops etc, it crashes the app. Mouse = OK. Trackpad = Unstable.
I work on a laptop a lot without a mouse and it is not a good stable environment. With a mouse, no problem as the drags and drops are a lot cleaner. I just save my source code a lot so I don't loose data. 8-/

LiveCode Forums.

Corrupted objects fixed by cut paste of them.

Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.

Re: Corrupted objects fixed by cut paste of them.