[Xiaolin]

hi,

i encountered a little problem when i have two controllists, where i let list2 be updated in the onaction() function depending on the active item in list1. i use getselectedposition() to determine the selected item in list1, and update list2 accordingly (naturally, this is only done if list1 actually has focus). however, it seems that in the onaction() function, list1 has not always been updated yet, resulting in an old return value of getselectedposition(). i worked around this by calling a little function in onaction() that starts a new thread, waits a bunch of milliseconds, and then calls getselectedposition() and updates list2. although that solves the problem, i still think this is strange behaviour for a gui callback. i mean, what's the point of a gui callback if the gui sometimes has been updated in the callback, while at other times it hasn't been?

[Asteron]

i have noticed this problem as well. onaction at different times seems to preceed or follow the action event. the fix to this is seen in my cnn script which spins off another thread which waits like 20 milliseconds (or something) and then reads getposition. it works but i thought it silly.

[Xiaolin]

yeah that's also what i came up with (as stated in the first post). funny that such a workaround is needed though...

[Asteron]

yeah that's also what i came up with (as stated in the first post). funny that such a workaround is needed though...

heh, my reading comprehension skills are not the best. it seems like there is an annoying race condition in there though... at least oncontrol works fine but it does make using movement events in onaction a pain..

[jmarshall]

if you have a nosy in cguipythonwindow::onaction() you'll see why this is occuring.

the python onaction message is fired before the base window class onaction() is processed, thus the control isn't updated until after you have dealt with the python message.

adding a 20ms delay thread like you've done gets around this, but perhaps a better alternative is to swap the order of these calls?

eg:

bool cguipythonwindow::onaction(const caction &action)
{
bool ret = cguiwindow::onaction(action);

// do python stuff

return ret;
}

ofcourse, a change like this will require us to check whether this will break any scripts that previously relied on the info in onaction() being before the real action was performed.

darkie: any comments on this?

cheers,
jonathan

[Asteron]

ofcourse, a change like this will require us to check whether this will break any scripts that previously relied on the info in onaction() being before the real action was performed.

i recall the onaction coming intermittantly both before and after the 'real' action.

[jmarshall]

yes, that is because the message sent is processed and fed to python in a different thread. if the message processing thread gets the message (and thus calls onaction in the script) before the base class has finished processing the message you'll get this sort of behaviour. if the base class finishes first you'll be in business.

doing the base class stuff before the message is sent should result in a more predictable behaviour.

please test it out if you have the chance.

cheers,
jonathan