Handling variable event data

[Ron]

Hmm, I see your point, what about this solution:

For set events like Idle, Stop, Play, etc etc use an eventstring like "idle", "stop", "play". Girder matches a command based on device number AND eventstring. So it should not be a problem that these are generic.

For events like track time set a prefix
DVDCODE:<TEXT TO APPEAR ON LCD>

I don't know if you are aware of this but there actually is a function in Girder that lets action plugins bypass the normal eventprocedure and get all actions that is subscribed to with a "prefix". See the log-plugin.

So your LCD plugin would subsribe to the "DVDCODE" prefix and just put the text after the prefix on the LCD. And the LCD-action plugin would also be able to program like any other plugin. Via the normal mechanism.

About the registers, action plugins have access to the registers, hardware plugins do not. ( It is possible for an hardware plugin to have both soft and hardware side though) but you want them separated so that is not he way to go.

What do you say ?

[Ron]

Yeah i agree,.. it would be of limited use then. So basicly a text register and hardware plugin access to this would solve this problem in a general fashion.

[Ron]

I've uploaded a Girder pre-release, this one includes text registers and most importantly the hardware/input plugins can now access registers.

Look at the download page for the source code to the SLinkE plugin ( for the headers and a hidden example ) I don't have time to write about it,... been working on the homepage all day and its 0.07 am now,.. so i'm off to bed.

Just ask ahead if there are problems.

-Ron

<font size=-1>[ This Message was edited by: RonB on 2001-05-17 00:11 ]</font>

[Ron]

The message processing of Girder is as
follows:

Plugin gets Semaphore
Plugin Sendmessage
Girder receives message
Girder copies data from message
Girder releases semaphore
Girder processes the event in same thread. ( thus no extra qeueing, the next event will not happen until this event has finished running, this is a point that should be changed, could become a major bottleneck. )


BUT, setting the text register is asynchronous. This can happen at just about any time.

Using the event queue for the regsiters would solve that, but it would not garantuee that if 1 plugin sets the register, and sends an event that the register still has the same contents,.. a different plugin could have pushed a register-event in between the other 2 events. Although highly unlikely.

This is something that i should explore,.. Girder didn't have this problem before the introduction of registers, thus there is no way of making sure that 2 events are processed exactly after eachother. Anyone any thoughts about how to tackle this without breaking the other plugins ?

[Ron]

Yeah i was thinking along the new WM_USER+.. line too. Then make the length of the shared memory buffer larger and add some fields in there.

buffer[500]
0-250 Event String
250 type
251 type
252-500 Type data ( eg. string )

And this last part gets dealt with right before the eventstring runs thru the tree. I'll have to add a register mutex around the tree to prevent plugins from changing it again... might be a good idea anyways.

[MMcM]

I have a standalone application that display information about the state of a software DVD player in a drive-bay LCD. It does things along the lines of those outlined in this topic (http://www.stack.nl/~stilgar/windoze/forum/viewtopic.php?TopicID=190). Receive disc insertion events and display something about the new disc. Hook windows messages for player state changes and display the current chapter, the elapsed time, etc.

It has been suggested that this would be better done using Girder. This is attractive, since the plug-in architecture gives a clean separation of event publisher and subscriber.

So, overall, there would be a "hardware" plug-in for the DVD players that monitors windows events and generates Girder events. And there would be an "action" plug-in for the LCD. What I am not clear on is how best to handle the variable data.

For the sake of analysis, let's simplify the problem. Ignore what is needed to recognize changes in the player state. Ignore how the LCD hardware is controlled. That is under control; it is just a matter of cutting and pasting some C++.

Suppose that there are two windows, W1 and W2. Whenever either gets a WM_SETTEXT, a hook will generate a Girder event. On the other end, put the I was here action. We want to display "One: " and the new window text for W1 and similarly for the other window. What is the best way to do this?

The event text could include the new window text, as in W1:<new text>. Then a special version of the action could register a callback for the W1 prefix and parse off the rest of the text itself. But that is not very general. The target knows too much about the source.

The event could just be W1 and the variable data could be put on the side. For instance, it could be in a register. Right now, those are only integers, but this post (http://www.stack.nl/~stilgar/windoze/forum/viewtopic.php?TopicID=223#1161) asks about text registers. Then the command for W1 would output "One: [treg1]". Can a hardware plug-in set a register, or only an action? Are register contents supposed to be completely under the control of the Girder "program" and not the plug-ins?

A downside of putting the variable information on the side is that it's harder to have a command for a particular event, such as "W1:Idle".

A hybrid approach would be to have a third plug-in action that took apart an event with a specified prefix and put the pieces into text registers. For instance, it could take a text delimiter.

What is the best course?

[MMcM]

I had seen the prefix callback API, yes, thanks.

If the LCD plug-in enables a callback for DVD, then it's not so much an LCD plug-in as a DVD-over-LCD plug-in. Then, when you want to display WinAmp information, you need to modify it. And again when you want your PVR to display program information from the EPG when you change channels. You've lost the modularity that is normally the great thing about Girder.

The prefix could just say, here's something that might be of interest to the LCD. So, the hardware plug-in would generate events like LCD:TM:00:05:00 for five minutes elapsed time. But then the action plug-in needs to decide where this goes on the display. Either it has its own idea, or the plug-in settings UI specifies. In either case, you're down the slippery slope of inventing new control structure constructs that compete with Girder's own.

That's why I'd prefer that the LCD action's UI just have (a) what position and (b) what text (and maybe fine details like wrap vs. truncate). Something associated with the particular command, rather than global to the whole action plug-in, says when to carry it out and makes the variable part of the text available for substitution within the display text.

Do you see what I mean?

And there's more to it than just engineering taste. From the users' point-of-view, they want to control what is displayed when. One might want the time of day on the top line. Another the CPU temperature. A two-line display can't hold as much as a four-line one.

[MMcM]

We are substantially in agreement, then.

As a workaround for the current Girder, what I have done is post the ancillary data in a second event that precedes the real one and begins with a magic prefix. Any action plug-in that needs to access the variable data registers a callback for this prefix that copies the rest of the data. This makes it available for action routines triggered by the real event. This keeps the overall modularity intact.

[MMcM]

On 2001-05-17 00:10, RonB wrote:
I've uploaded a Girder pre-release, this one includes text registers and most importantly the hardware/input plugins can now access registers.

Great. I have made the necessary changes to use this new mechanism rather than the workaround and will email you the updated version.

[MMcM]

Am I right that the arrival of an event through the semaphore / shared memory segment / user message and the processing of associated actions are asynchronous? That is, that the semaphore is reset as soon as the event has been queued internally?

This leads to timing problems with the use of text registers as event parameters. It is possible for a subsequent event to overwrite the register before the action from the previous event has read it.

One way around this within the current framework would be to use a different register for every event, or at least every event that might occur in close proximity. That is not hard to do, but it does imply a level of coordination that I am not entirely comfortable with.

Everything else requires some kind of additional synchronization within the publishing mechanism itself. For instance, a way to set a [text] register within the data written to the shared memory segment or a version of the setting functions that enters the change into the same queue rather than making it immediately.

Let me know what you think.

[MMcM]

To keep it simple, we could put synchronous register setting within the message data, along with the "IR code". To avoid affecting existing plug-ins, we could use some non-character byte that is unlikely to be in any event today as a separator. Or we could post a different wakeup message than WM_USER+1030 to mean that the data has a new extended format.