Troubles come in many Forms

[P3rv3rt B3ar]

As title suggest ive run into form trouble. This might be totally newb form user question, but hey thats why developer forum exists.

So im trying to run a form from my plugin dll. When i do this within XlobbySDKs showDialog() function it is working beautifully, but when i try to run exact same form on other times, especially when skineditor is brought up, form just freezes up, its components are not drawn, and when u move mouse on it u get that hourglass icon. If u call refresh, afterwards generating and showing form, components are drawn, but form is still frozen with hourglass... that is weird though cause theres no need to call refresh when u generate form within showDialog()...

I even thought that XL doesnt somehow bother to manage forms on other times, and found out window handle of desktop and delegate showing of my form to it, this was off no use...

Any ideas what im doing wrong? are we supposed to manage forms somehow? for what r we paying Mr. gates then??

EDIT also found this thread http://xlobby.com/forum/viewtopic.php?f=14&t=4628&hilit=+form about other but surprisingly similar form troubles... and followed Badubo's suggestion to create form when helper is set yet showing it as skin editor is diplayed, sadly it makes no difference in my case

[P3rv3rt B3ar]

Ok... experiment more with Babudos advice... turns out forms need to be flashed too... when i add

Code: Select all

 
myDamnForm.show()
myDamnForm.hide()


within sethelper() its working... uhhh these are moments i feel like a true _windows_ coder.

I thought it was only us Finns fond of skindipping... but it seems to be totally formal activity.

[P3rv3rt B3ar]

Ok i did bit more research on this... for my problem reason is not so much the fact that thread dies (u can keep the thread in lifesupport yet the form fails)... but the fact that threads message queue isnt handled. If u call application.run() in your thread its messages will be handled, so this way u can make other threads responsible of creating forms too. (ofcourse if thread dies, i believe, dialog wont work anymore, so supposedly best solution is create new thread to manage the dialog, and life support it as long as needed.)

EDIT: for codenewbies... bears life support means:

Code: Select all

while(plugged)Thread.Sleep(10000);

[m_ski]

I had lots of similar trouble to this in my xTransition plugin which keeps a separate form alive all the time xlobby is running but just shows and hides it when it is needed. As you said, the big problem was handling the message queue and the only way I got around that was to create the form in its own completely separate thread and then send messages to it when the plugin commands are executed.