Hey Omer, 2010/1/19 omer katz <[email protected]>: > Currently I have a function that triggers updates whenever my slider's value > changes: >> >> void updateChanges() >> { >> wApp->enableUpdates(); >> Wt::WApplication::UpdateLock lock(wApp->getUpdateLock()); >> wApp->triggerUpdate(); >> }
The enableUpdates() and triggerUpdate() methods are used to push visual changes of a particular application to the client, from outside the event loop (another thread or, like in the simple chat example, another application). So you either need to at least have another (worker) thread or intra-application communication for these methods to be useful. > Unfortunately it doesn't update the slider like it's expected to. If it was a client event that ultimately resulted in a slider value change, then it should be propagated when the event handling finishes. If you have a long event handling, then you can use WApplication::propagateChanges() to update the user interface at intermediate time points. However, this solution is inferior than using a worker thread because it still freezes the user interface while the event handling is busy. > The documentation doesn't show examples for updating widgets. Because widgets are updated automatically. > What are the requirements for updating widgets? > How does a widget knows it's contemporaries? Every widget keeps track of changes to it. Regards, koen ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
