Hello Marco, I'm not sure I understand your question, but I think you are referring to our server push infrastructure. With server push, you can replace the WTimer events with server-initiated GUI updates.
Traditionally in the http-world, the client must initiate all requests, so the server has only the possibility to interact with the client at the moment that the client performs another request. Hence, the timer, to check for updates from time to time. However, more recently, people started to develop techniques where the server can initiate communication to the client. In the implementation, it is still the client that opens the connections (otherwise this would not work through proxies and firewalls), but in it's use, it is as if the server can initiate communications to the client. In Wt, this is implemented in WApplication::triggerUpdate(). The chat example is an example of a server push application. I should warn that at the moment, certain proxies make the use of server push on the broad internet sometimes unreliable. Let's hope this changes in the future. Best regards, Wim. 2009/1/21 Marco Faletra <[email protected]>: > Thank's for your replay. > > Is there a very, very, very little example with Boost signal and Wt? > Also schematic, does not have to be with source code. > Because, sincerely, I don't like use WTimer for query the state of the > application from time to time, but I could wrong. Which do you prefer? > > Bye. > > 2009/1/19 Wim Dumon <[email protected]> >> >> Hello Marco, >> >> No, you cannot use a WTimer outside the context of a session. >> >> What you should probably do: >> - In main(), start a thread where you perform your CAN-bus related >> work. Everything that the system has to do regardless of who uses the >> user interface, is to be done in this thread. Feel free to use sleep() >> to make this thread wait for a while; this will not block the >> interactivity of Wt. I would recommend not to update the widget tree >> from this thread (in any case, lock the Wt threads if you plan to do >> so!), but query the application state from time to time from within >> the GUI threads. >> - Call WRun() to start the user interface >> - Let the Wt GUI query the state of the application from time to time >> (e.g. using WTimer objects), making sure that you lock your data >> structure (e.g. using mutexes) when appropriate. >> >> Wt uses boost's signal library, and you're free to use that too in >> your threads. Note that the boost signal library does not protect you >> from concurrency problems, that remains your responsibility. The Wt >> threads can be locked by calling WApplication::getUpdateLock(). >> >> Regards, >> Wim. >> >> 2009/1/19 Marco Faletra <[email protected]>: >> > Hi all, this is my first post. >> > >> > First of all "Well done WT's boys" for your work! >> > >> > Also I would want to make an application like this, with a part that >> > communicates via CAN-bus and front-end via web. >> > This application must work also without a connected browser. >> > I have read that I can do this with WTimer in the front-end side that >> > read >> > the state of communication, but is it possible using "signal/event" in >> > an >> > application like this, without the GUI uses the WTimer to refresh the >> > internal state? >> > I have tried to write a program with a thread before WRun, but when it >> > send >> > the "emit" the program crash (I think because the sender of the emit is >> > in >> > another thread)! >> > Is it impossible create a WTimer before WRun or without that a browser >> > start >> > a comunication with http server? >> > >> > Regards, >> > Marco. >> > >> > >> > ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by: >> > SourcForge Community >> > SourceForge wants to tell your story. >> > http://p.sf.net/sfu/sf-spreadtheword >> > _______________________________________________ >> > witty-interest mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/witty-interest >> > >> > >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> witty-interest mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/witty-interest > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
