[Scilab-users] bug when setting gcbo field in a callback function ?

[antoine monmayrant]

Hello Stéphane,

Well, I tried exactly this trick with mixed results: it kind of works 
most of the time, but sometimes it fails.
I did not manage to reproduce the issue with my minimum working example 
though.

It's weird, no?
Why would gcbo behave differently than h?

As for why "set" is working, while "gcbo.whatever=something" is failing, 
I think it's because something goes wrong when scilab is parsing 
"gcbo.whatever=something".
It is as if scilab forgot about the fact that gcbo exists and does what 
we expect when creating a struct:
     doesnotexists.whatever=something;
creates a "doesnotexists" struct with one field==something.

Antoine


Le 29/09/2018 à 00:04, Stéphane Mottelet a écrit :
> Hello Antoine,
>
> Never trust the life time of gcbo, and first copy the value of gcbo 
> like this:
>
> function  funcb1()
>     h=gcbo
>     disp(typeof(h));
>     h.callback_type=-1;
>     disp(typeof(h));
>     h.callback_type=0;
> endfunction
>
> With this trick the type of h is always a handle. However, I cannot 
> explain why the second syntax using set() always works...
>
> S.
>
> Le 28/09/2018 à 21:00, antoine monmayrant a écrit :
>> Hi all,
>>
>> In a callback function, gcbo is a handle to the calling uicontrol.
>> There are 2 ways to set one of the fields of this handle (let's take 
>> "callback_type" as an example):
>>     (1)    gcbo.callback_type=-1;
>> or equivalently
>>     (2)    set(gcbo, "callback_type",-1);
>>
>> In theory, both are perfectly equivalent.
>> In practice however, (1) leads to recurrent issues where gcbo is no 
>> longer a handle, but a structure!
>>
>> See below  an example script showing the difference:
>> - two slides with equivalent callback functions funcb1 and funcb2, 
>> but for the different syntactic sugar (1) or (2).
>> - if you play with the top slider in the figure, everything's fine, 
>> gcbo remains a handle (see output on the console).
>> - if you play with the bottom slider in the figure, gcbo turns into a 
>> struct (see output on the console).
>>
>> Needless to say, this kind of issue made my GUI debugging session 
>> really fun.
>> To make things even more fun, if you "pause" then execute "funcb1()" 
>> step by step, you don't necessarily trigger the bug, it's quite 
>> random and fairly unfrequent.
>>
>> Can you try to reproduce this bug on your computer?
>>
>> Cheers,
>>
>> Antoine
>>
>>
>> // BUG_gcbo_set.sce //
>> h=scf();
>>
>> hs1=uicontrol(h, ...
>>     "style", "slider", ...
>>     "tag", "slide1", ...
>>     "backgroundcolor", [1 1 1], ...
>>     "value", 0, ...
>>     "min", -100, ...
>>     "max", 100, ...
>>     "sliderstep", [1, 10], ...
>>     "position", [20,40,200,20], ...
>>     "constraints", createConstraints("border", "top"), ...
>>     "callback", "funcb1");
>>
>> function  funcb1()
>>     disp(typeof(gcbo));
>>     gcbo.callback_type=-1;
>>     disp(typeof(gcbo));
>>     gcbo.callback_type=0;
>> endfunction
>>
>>
>> hs2=uicontrol(h, ...
>>     "style", "slider", ...
>>     "tag", "slide1", ...
>>     "backgroundcolor", [1 1 1], ...
>>     "value", 0, ...
>>     "min", -100, ...
>>     "max", 100, ...
>>     "sliderstep", [1, 10], ...
>>     "position", [20,80,200,20], ...
>>     "constraints", createConstraints("border", "top"), ...
>>     "callback", "funcb2");
>>
>> function  funcb2()
>>     disp(typeof(gcbo));
>>     set(gcbo, "callback_type",-1);
>>     disp(typeof(gcbo));
>>     set(gcbo, "callback_type",0)
>> endfunction
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>