Add a new command, watch Girder crash!

[Ron]

I think you are right Mark!! Great work! :P

[Ron]

Found and fixed! I'll be releasing a 3.1 girder shortly to fix a few important bugs. Not everything is fixed in there as the main developement is in the 3.2 tree.

By the way I like the topic

Add a new command, watch Girder crash!

Sounds like some advertisement slogan! Maybe I should hire you for PR Mark :wink:

[Ron]

Could you give 3.1.3 a run if you have a minute ?

[Ron]

Right on the money Mark! there is one global structure that I pass to all plugins. That brings another problem to mind, what if 2 plugins are open and one modifies ... will that bring problems ??? I'll extend Girder 3.2 to have 2 private command structures in the plugin data structure. That should solve the problem.

update: on second though the problem that I described would also be solved by a command_changed call after another plugin modified the command. So your solution is perfect and easy to implement.

[Ron]

I'll update 3.1.3 tonight to fix this.

[Ron]

Released 3.1.3b

* adds two separate structures as suggested by Mark
* notifies all plugins of a change by a plugin

[Ron]

I'll run some torture tests tonight. :P

Please be gentle :lol:

[Ron]

Mark, that house of yours sounds like a Paradise :-) do you rent out rooms too ?

I think I know what that is. Why do mutexs work differently on Win9x and Win2k ? :x

update: Well I be *beep*, it fails on win2k too :oops:

update II: fixed in 3.1.3c

[Mark F]

I'm updating one of my plugins to use API 6 and I've been chasing an elusive bug that I assumed was in my plugin but it looks like it is in Girder. :(

Here is the scenerio:

Start Girder
Open a .gml file that has a command for a plugin in it.
Click on the command and press settings button (a dialog appears)
Use button 2 to create a new command
Use the already open dialog to set up the command and press apply or OK

At this point the command tree is hosed. If you've used the extended data area (binary and size), prepare for a crash. :(

In step 3, a command pointer is given to the plugin. In step 5, the pointer from step 3 is used to update the tree because step 4 does NOT pass a new command pointer to the plugin. Man was this hard to track down!

The question is, now what? It is impossible for Girder to know which plugins have dialogs open so what should be done when a new command is generated?

Right now, in step 4, I get calls to command_clear() and command_controls(). I think all software plugins need to get a command_changed() call, too. What do you think?

I found this on Girder 3.1.2e and 3.2a9 using Win '98 and NT 4.

[Mark F]

Yeah, I'm not sure how many you'd "sell" with a slogan like that. :D

[Mark F]

I'll need to do this at home this evening. Work calls. :(

[Mark F]

I carved out some debug time at lunch and now have mustard all over my keyboard. :)

The 3.1.3 change is helpful but I've hit another problem. It appears you reuse the same command data structure (at least you pass the same pointer) for the UI and the event processing portions of Girder. This means the pointer to a command a plugin gets to update a dialog (through command_changed() or command_gui() ) may have the command contents changed if an event is processed (walking the tree) while it holds the pointer.

I'm big on scenarios so bear with me. :)

Chose an event in the tree
Press settings (filled in dialog appears and has focus)
Change the values in the dialog
Press apply or OK


If an event comes in and is processed between steps 2 and 4, the values in the command structure received in step 2 are changed to the commands that are executed because of the event. HOWEVER, because Girder does not have focus, it doesn't show the results of walking the tree and, more importantly, the plugin does not receive the command_changed() calls.

I really think you need to keep two command data structures. One that you pass through the command_execute_ex() interface and a different one you pass through the command_changed() and command_gui() interfaces.

I'm debugging this from outside your program so I could be way off. This is the only plausible explanation I can come up with by inspecting the data passing through my plugin. :) I hope this helps.

[Mark F]

I re-ran the test from lunch and it works great. :)

I'll run some torture tests tonight. :P

As usual, excellent support. 2 hours from bug report to fixed release version. Is this a new record? ;) Thanks Ron.

[Mark F]

A quick update -

I haven't done all the testing I wanted. :( Instead, I had an empty network attached storage server and the 2 drives that go in it (240 GB total :o ) sitting on my front porch when I got home. I installed that onto my home network last night. My music collection, source code, Girder files, applications and assorted data now has a permanent home that is accessible throughout the house. My wife is pleased. :D

Back to Girder.

I've done some more testing this morning and I *think* the pointer problems are gone!

A new problem: One aspect of the Simple OSD seems broken in 3.1.3b. I have [pld1] in the Icon/Device field and I get a dialog box with the title "error" and the message "Register Failed" the first time this command is used. I get NOTHING (no popup, no OSD, no error) every time this command is used after the first. Substituting the OSD Popup for the Simple OSD produces the correct results. Substituting 3.1.2e for 3.1.3b produces the correct results, too. This is on Win '98.

[mattwire]

The problem you have discovered is probably the same thing which was causing problems with osdmenu when it sent a command to girder at the same time as running command_execute_ex. The curcommand structure was returning null values for everything when this occurred.