Whenever a context menu is open, it seems that no code is executed anymore until the menu is closed. I doesn't matter if i open a context menu in my own windows or anywhere in the development environment, the effect is always the same. The same happens while a window is being moved with the mouse. I tried forking processes with different priorities, but all of them stopped execution as long as the menu is open/ the window is moved. Is there any way to create a non-blocked background process? The only thing that comes to my mind is calling a c-program (dll) and let it fork, resulting in a new "real" process on operating system level (but then i would have to split and restructure a big part of the program).
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Hi Paulson,
On Wednesday, May 15, 2013 7:38:08 AM UTC-4, Paulson wrote: Whenever a context menu is open, it seems that no code is executed anymore until the menu is closed. I doesn't matter if i open a context menu in my own windows or anywhere in the development environment, the effect is always the same. The same happens while a window is being moved with the mouse. I tried forking processes with different priorities, but all of them stopped execution as long as the menu is open/ the window is moved. Is there any way to create a non-blocked background process? The only thing that comes to my mind is calling a c-program (dll) and let it fork, resulting in a new "real" process on operating system level (but then i would have to split and restructure a big part of the program). I have been bother by this too but haven't looked into a solution. I have a feeling there isn't an easy one. I have some GUI programs that are talking (TCP/IP) to Windows NT services (also my programs) in the background and if a menu is open for awhile, the connections timeout. They auto reconnect but it is still quite annoying to users. So, I would love to see a fix/circumvention for this. Lou
-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
In reply to this post by Paulson
Hello,
that's the way I would think of. It gives you much more freedom how to develop the GUI. It has been a long time when I created my last native client with VA. Over the last two years I only write headless systems in VA - and create either an embedded Seaside GUI (mostly jQuery Mobile GUI) or even a Javascript GUI. This seems - for me - the much safer future to survive with Smalltalk - and you may get rid of the multi-core problems with Smalltalk in general. Marten Am Mittwoch, 15. Mai 2013 13:38:08 UTC+2 schrieb Paulson: The only thing that comes to my mind is calling a c-program (dll) and let it fork, resulting in a new "real" process on operating system level (but then i would have to split and restructure a big part of the program).-- You received this message because you are subscribed to the Google Groups "VA Smalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at http://groups.google.com/group/va-smalltalk?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Free forum by Nabble | Edit this page |