Problem using open_script_editor()

[Mark F]

I'm using this interface in the Serial plugin and am having a problem.

The serial plugin starts a thread for the settings UI dialog (when the gir_config() interface is called). This dialog has a button that will call open_script_editor(). When called, the script editor is displayed but the keyboard and mouse don't work on the editor window buttons and fields. If I cover the editor window with a different window (IE, Outlook, etc), any pent up keystrokes get through and when uncovered, it works fine.

I have been seeing this for a while. I have a set of steps that will make this happen 100% of the time on NT 4.0 and ~30% of the time on Win '98. You only need to unzip the .dll file and enable the serial plugin before doing these steps.

start Girder
File/settings.../plugins, highlight "Generic Serial Support" and press settings
press new
type "fire" into the text field
in the device enable group, check script, press define

The editor window should be visible but not usable. If it is usable, cancel the windows and start at step 2.

I'm at my wits end. Sorry. :(

[Ron]

You'll need to run your dialogs on a separate thread. At least that's what I did for HTML OSD. It was having these strange problems too.

[Mark F]

A separate thread from what?

The serial plugin starts a thread for the settings UI dialog (when the gir_config() interface is called).
Do I need a different thread from this new one for the open_script_editor() call?

[Ron]

You'll need to run the configuration dialog that you popup on a separate thread from what it is called. At least in popupOSD you run the configuration dialog on the EventQueue thread, that gives some problems, most notably keyboard problems.

edit: sorry I'm not 100% awake, you said it has its own thread... lemme think

[Ron]

I'm puzzled, the Treepicker uses exactly the same code, only difference, the treepicker works. :(

[Ron]

:roll: I think I'm coming down with the flu or something ...

anyway here is there working code:

ftp://ftp.stack.nl/pub/users/stilgar/Girder326pre6a.zip

I moved out some legacy code (dating back to 3.0 i think, its always the last bits of old junk that get you. ) and reworked it.

Note to self: its probably a good idea to redo the treepicker code too.

[Mark F]

Initial test -> success! I'll do more later. Thanks. :)

[Mark F]

The new code causes a different problem. :(

When "run script" is chosen (via button, F5 or menu item), nothing shows up in the lower window pane.

When I try to exit Girder after this I get an error message about an invalid window handle, 3-4 references to invalid instructions and runtime error 216.

The new code appears to work fine when building a command using the editor from the Girder tab.

[Ron]

great. I'll look into it.

[Ron]

okay, I think I've fixed all problems now ( the famous last words :-D )

http://www.girder.nl/temp/Girder326pre6b.zip

[Mark F]

Good news and bad news.

Good news: The mouse and keyboard work and the run script works. :D

Bad news: I get an unhandled exception error when exiting Girder after using the script editor from my plugin. :(

This is every time on NT 4 and once in four tries on Win '98.

[Ron]

Thanks I've found that too, although sporadically, so this seems to be some threading issue. Might take some time to squash this one.

[Ron]

I have been able to find what was causing the errors on my system. No wonder they where sporadic. The Hints where not being cleaned up properly... Though my gut feeling says this was not the root-cause, but now the errors have gone so I'm not sure this fixes it 100%. I would appreciate if you'd give this executable a spin.

http://www.girder.nl/temp/girder326pre6c.zip

[Mark F]

No joy. :( Pre6C still causes exceptions on my Win '98 system. I'll have to wait until tomorrow to try it on NT.

[Ron]

okay... Why don't i see this on my system :(

[Ron]

I think I found the "Root of all Evil" (c), its the threading, the VCL isn't multithreaded. Thats why I originally had the editor on the main thread, but that was causing some nice redraw problems. I guess it has to go back onto the main thread, but with some different code.


references:
http://www.experts-exchange.com/Programming/Programming_Languages/Delphi/Q_20041229.html

[Ron]

Another attempt,

The original bug is back, but I'm not sure this is girders fault as a plugin by me does not show this behaviour. :(

http://www.girder.nl/temp/girder326pre6d.zip

[Mark F]

I'll have to do more investigation at home. :(

[Mark F]

I was trying to answer a user question and ran across this easy scenerio. Maybe it will help to reproduce the problem I'm experiencing.

rename the plugin directory to remove all plugins :)
start Girder (pre6D)
add command
Girder tab, GVMS, press the script button
move the script editor so you can see the learn event button on the main Girder window
without changing focus from the script editor, press the learn event button

When I do this on NT 4, Girder is completely locked up at this point. It doesn't paint correctly, doesn't respond to input and has to be closed using the task manager. :(

[Mark F]

Sorry, I made the above too complicated. :)

Rename the plugins directory
Start Girder
Add command
Press learn event

Crash.

[Ron]

whoops some testing code remained behind. ( yes that is supposed to crash, it blocks it selfs ).

http://www.girder.nl/temp/girder326pre6e.zip

[Mark F]

I think part of the problem is the nature of the thread I'm using to make the call to display the editor window. Since this is a UI thread and you are blocking it, no messages are being processed on that thread while the editor window is open. I'm not sure what the behavior is supposed to be if the "change focus" messages cannot go through.

I'll do some experimenting at home when I get a chance but I'm thinking I'll need to rework my plugins to not call the command tree or script editor interfaces from UI threads. :(

[Ron]

I'm sorry I can't help much with this. With the current implementation there is nothing else I can do.

[Mark F]

I was able to make this work this morning. I spawn a new thread that calls the open script editor interface while the previous thread continues to process messages.

This will take some time to clean up but I should be able to get this done soon.

Thanks for trying so hard to get around my limitations. :D

[Ron]

Its almost ludicrous that you'd have to start a new thread for this, but I see no way around it,.. I did search for a couple of days for a better solution but nada... I can of course always implement a different way of doing things. Something like a non-blocking call to script_window and a window message that is sent back when the user is finished.

[Mark F]

Just so you know, in the 6e version above, if I use the print() function in the middle of a LUA script, the script stops processing after printing to the output pane. If I use the pre6 on the download page, this is not the case.

I know you were doing some major code changes to the script editor code to try to solve my problem. Did one of those blow this up? :(

[Ron]

yeah this one probably blew up in my face :( I'll revert it. ( Great thing I switched to CVS )

[Mark F]

The serial 3.0.8 plugin has this fix.

[Ron]

Did you have to revert to using separate threads ?

[Mark F]

Yes. :(

[Ron]

no fun.

[Ron]

Mark I noticed that there where even more problems with the script editor... I hope I have been able to fix all nastiness now in Girder 3.2.6b. ( I've tested with Serial 3.0.8 and it seemed to work fine now ).