Girder 3.2 alpha 1,2,....

[Ron]

Well, as you might have seen I'm working on a new input event queue. Girder 3.2 has 3 goals:

1. Fix the antirepeat problem
2. Fix the input queue lenght
3. Separate Core from UI

1 and 2 are pretty much in, but have seen little testing, 3 is coming along pretty good, there are just a few more loose ends to tie before that is done aswell. A 4th goal is the NT server option, if this will make it into 3.2 is not yet sure.

As always I need your help to find and squash the bugs, the more you help the faster you'll have Girder 3.2

Disclaimer: don't use in a production environment yet.

[Ron]

I still have my antirepeat problem. In reality I'm holding down for 300ms or so but I have to set the timeout to 8000ms (longer than my command runs) for it to not repeat.

Well I have no clue why this is, the antirepeat really works as advertised now, the event is timestamped when it enters Girder and compared to the old timestamp. Mind you, the antirepeat works on a per-action basis not on a per event basis maybe this is your mistake.


I noticed another thing. I'm using the same remote to control the volume on my amp, directly - not trough Girder. But still Girder registers the volumekey event and will beep the antirepeat/buffer full warning while I'm holding down to raise or lower the volume.

Well of course girder will see this key if your irman sees it. I have no clue why it beeps though.

[Ron]

The OSD Window (created by the OSD Popup plugin) doesn't seem to get the WM_TIMER message for it's timeout.
You are not using the built in OSD right ? I mean girder is not responsible for the WM_TIMER thing.

* checking the payload stuff.
* checking the registercb stuff.

[Ron]

oh no that is bad news. That probably also means that the slinke plugin needs updating. Anyone feel like maintaining a plugin ( I'm not asking you Mark :-) you are busy enough )

[Ron]

Yep that is broken

[edit: and fixed :-) ]

[Ron]

Alpha 2 released it fixes:

* Payload
* EventCallback
* Treepicker

[Ron]

PostMessage doesn't trigger any other actions. So that isn't the problem. Could you send me a simple file that demonstrates the problem.

[edit] forget this, of course postmessage can trigger other commands.

The commands that you trigger from an action plugin with a postmessage will not adhere to the anti-repeat. Which is the way it is supposed to be. Only events generated by a hardware plugin will go through the anti repeat check.

Please give more information on the exact problem.

[Ron]

Please also report version. I cannot reproduce any of your bugs in Alpha 2.

What window are we talking about ?

[Ron]

Matt, the alarmtimer problem is fixed, I have not seen the crash after the alarmtimer thing though. Can you send me an example when it crashes ?

[Ron]

I tested it,... it worked for me. Maybe you can send me the code so I can see what is going on.

[Ron]

This is weird, it works for me Mark. Though I am using a slightly newer version.

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

Can you try if this one works ?

[Ron]

Mark, are you using the unmodified userevent.dll 1.0.1 and the simple osd ?


I really hope i do not have to install win9x.

[Ron]

Mark, I've added a trace function to Girder it will log incoming events and payload lengths in 'c:\girder32trace.txt' could you run it on the 'user event.gml' ? Here is my output:



1848277: Open Trace
1848688: Hardware Event, device:18 payloadlen:0
1848688: Queue thread, event on queue, device:18 ir:GirderOpen payloadlen:0
1852143: Hardware Event, device:18 payloadlen:0
1852143: Queue thread, event on queue, device:18 ir:GirderEnabled payloadlen:0
1853795: Hardware Event, device:1 payloadlen:27
1853795: Queue thread, event on queue, device:1 ir:575000000000 payloadlen:14
1853805: Hardware Event, device:142 payloadlen:46
1853805: Queue thread, event on queue, device:142 ir:Hello payloadlen:40
1858892: Hardware Event, device:18 payloadlen:0
1858892: Queue thread, event on queue, device:18 ir:GirderClose payloadlen:0
1858933: Close Trace


The file

(removed)

Thanks!!

[Ron]

Mark, I see your problem with WM_TIMER... the calling thread does not have a message queue thus the plugin never receives this message,..

Should be fixed.

[Ron]

Thanks for your patience with testing, the move to a separate capture/event thread turns out to be pretty tricky, lots of places in Girder that are/where not thread safe. I'm working to find them asap!! All the testing is _very_ appreciated! Alpha 4 is coming up.

About the corrupted file, probably uploaded in ASCII mode :roll: Never mind,.. if alpha 4 still doesn't work I'll prepare another trace version.

[Ron]

Anyone interested please try

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

[Ron]

Some nasty access violation stuff with 'select girder event' window. Trying to work out an easy way to reproduce....hmm, managed to get piles of 'priviledged instruction' errors now...
Ok. try: select 'girder event'>press learn event>press cancel>press cancel learn>press learn event>press cancel>press cancel learn>press learn event (crash).
Is fixed in alpha 4

[Ron]

Isn't the compatibility across windows versions wonderfull :evil:

I'll install win9x later this week when I get some time again.

[Ron]

Well I installed win9x,.. this took about 1 hour, finding the bug took about 1 minute, was it worth it ? :-)

Anyways here is alpha 5

http://www.girder.nl/download.php?Link=279

Please test this one!!

[Ron]

:oops: a mutex fouled up, it was created with initial ownership, somehow win2k released it without me actually telling it to :-? while win9x did not release it (which seems to be the way it should have been. ) and thus never got into the payload subroutine. Anyways this mutex was an artefact from the old architecture so its out.

[Ron]

Mark, I hope your house is still in one piece! I'm glad that alpha 5 appears to work... now we need major testing by lots of people!

[Ron]

Wow that is actually good news, I'm glad the new queue is holding up this well.

About the maximum queue length, forgive me for I have sinned ;-) there is non, well system memory is the maximum length. I implemented it as a (linked list) FIFO as you originally suggested. I basically mixed your idea with mine.

With trap you mean a crash ? ( That might be Texas lingo :-) ) Glad to hear nothing serious happened in the storm! I'll try to do my own testing this weekend. Thursdays and Fridays are just too busy for me,.. taking classes and teaching a C course takes up about all the time there is.


Keep them reports coming in people!! If I do not get any I'll assume that Girder 3.2 is working perfectly and release a full version. And if you complain after the release about a bug I'll just ignore you :lol: okay just kidding

[Ron]

Quickly before my first class starts: I modified the internet event client into a stress tester, 10000 events witin 2 seconds ! And I can see a definate memory leak. this is probably what is causing the crash for you. I'll investigate ASAP.

[Mark F]

Sorry, that doesn't work either.

I have removed all the plugin files from the subdirectories except the UserEvent.dll file in the hardware directory. I'm using the rest of the files from a 3.1.2e install. My machines are running Win '98 and ME.

I don't know what to say. :(

[Mark F]

This may be my setup but the OSD PopUp and Logger plugins don't seem to work with this Alpha. (Win '98 or ME) I'm debugging as I write this but what I've found so far:

The OSD Window (created by the OSD Popup plugin) doesn't seem to get the WM_TIMER message for it's timeout.

The payload data seems to disappear (size is 0) between the time when it is given to Girder to when the event is given to the action plugin OR event handler of a RegisterCB function.

When a plugin calls the RegisterCB function with NULL (to un-register the callback), the next event causes a fault.

The logger window won't paint.

On the other hand, the Serial and UserEvent plugins are much more responsive than before. :)

[Mark F]

You are not using the built in OSD right ? I mean girder is not responsible for the WM_TIMER thing.

Right. The responsibility is mine.

I create dialogs and windows on the current thread of execution. In the case of an OSD PopUp event, this is whatever thread of Girder's that calls into my plugin. This used to work, it doesn't with the Alpha.

I'll need to change my plugins to spawn their own UI threads. This will take a while.

[Mark F]

I still see no payload data with Alpha2.

The logger and popup plugins are just about done but I need to leave so I'll finish them another day.

[Mark F]

I just downloaded and tried the UserEvent plugin and sample. This shows the problem. :)

The Send Event command sends an event with 4 pld strings. The receive event displays all using the simple OSD.

I get a completely blank OSD using 3.2A2 and all four strings using 3.1.2. :(

[Mark F]

I'm at work so I won't be able to do much testing today. I will check this out on NT 4, though.

I am using the files from the UserEvent.zip file from this site.

According to WinZip 8.1, the trace .zip file in your post is corrupted. I can't use it.

At home, I have altered the OSD Popup and Logger plugins to spawn their own UI threads to remove any dependancy on the Girder event dispatch thread. Thanks for checking into this though. It may let other plugins continue to work. I still generate dialog boxes on the same Girder thread when called to display or update a UI for a plugin.

[Mark F]

Testing is no problem. :) If this was easy, everybody would be doing it. ;)

BTW, I tested 3.2A3 on my NT 4 machine and it works fine. :)

Before you install '98 or ME, let me go home tonight and reinstall Girder 3.1.2e clean. Then I'll add 3.2A4 and see what happens.

[Mark F]

I just tried 3.2a4 on Win ME. It doesn't work. :(

[Mark F]

IT WAS WORTH IT! ;)

I'll try it at home tonight. If you don't mind, what was it? Thanks.

[Mark F]

Artifacts and side-effects. These are a pair of my FAVORITE things. :D

I'm glad you were able to reproduce (and fix) this.

[Mark F]

a5 appears to work. I can't test much as we have a bad storm headed our way. 3 tornados spotted already! :evil:

[Mark F]

It huffed and puffed but didn't blow my house down. :) I did SOME testing before getting into the bath tub for shelter.

I was using a remote with a "hat" (joystick). It generates continuous 4 byte reports at 2400 bps. The system was using the GVMS along with the logger, serial and userevent plugins. Each report is parsed into bytes using GVMS and the bytes are interrogated to decipher the direction the hat is pressed. This causes a user event to be enqueued for that direction (Right or Left or Up or Down). Another event handler triggers off the direction event and moves the mouse pointer. My Dad used to call things like this "going around your elbow to get to your nose" (not the shortest route) but it stresses the system and my plugins pretty well. :)

This setup would work REALLY WELL in spurts (15-45 seconds). The mouse pointer was responsive and accurate. Then Girder would trap. I removed the logger plugin and the time went up before the trap but the trap would still happen.

I know I need to do more investigation to narrow this down a LOT but I thought a preliminary report might help. :) There may be problems around the limits of the new event queue. Possibly around the full condition.

The event records (event string + payload data) I was sending ranged in size from 4 bytes to 50 bytes, if that matters. I don't know if you are using a fixed or variable sized event structure.

By the way, Grider 3.1.2e immediately gets swamped by events in this same scenerio. ;)

[worldrave]

Hey Ron, that definitely fixed that weird antirepeat problem.
Works like a charm now!!! Thanx again for your help with trying to help me troubleshoot that, AND fixing the bug anyway. Much thanx!!! :-)

-Dave-

[mattwire]

Can anyone confirm that:
Supportfunctions.Treepicker
is not working correctly on 3.2?
There is no reaction when pressing any of the 'browse' buttons on either Alarmtimer or OSDMenu.
Both of these are API6:
It appears to be returning a value of 0 everytime it is called.

[mattwire]

Girder Events don't work? - girderopen.

Problems relating to 'Girder event' window (event learning):
Why is window resizeable?
Should be modal?
Cancel should also cancel learn?


Some nasty access violation stuff with 'select girder event' window. Trying to work out an easy way to reproduce....hmm, managed to get piles of 'priviledged instruction' errors now...
Ok. try: select 'girder event'>press learn event>press cancel>press cancel learn>press learn event>press cancel>press cancel learn>press learn event (crash).

[mattwire]

Sorry! Alpha 2.
I've just done some 'investigating'. Is alarmtimer setup to halt execution in the current path when called? Because anything after it is not executed (girder 3.1/3.2).
Also, the access violation I described:
This happens (in alpha 2) only after alarmtimer has been called.

I was talking about the following window:
caption: "Girder Event"
class: TForm9

[Snakebite]

I still have my antirepeat problem. In reality I'm holding down for 300ms or so but I have to set the timeout to 8000ms (longer than my command runs) for it to not repeat.

I noticed another thing. I'm using the same remote to control the volume on my amp, directly - not trough Girder. But still Girder registers the volumekey event and will beep the antirepeat/buffer full warning while I'm holding down to raise or lower the volume.

And a low-priority bug in the GUI:
- select an event in the tree,
- close related command by directly clicking the [-],
then the command is automatically selected but the antirepeat inputbox is still enabled, but does not register. Invert and Enabled does also not reflect the command correctly.

[Snakebite]

Well I have no clue why this is, the antirepeat really works as advertised now, the event is timestamped when it enters Girder and compared to the old timestamp. Mind you, the antirepeat works on a per-action basis not on a per event basis maybe this is your mistake.


Could it be that my plugin is firing off additional commands (PostMessage) during one execution and Girder see those as the "last command" when it's time to check for antirepeat?



Well of course girder will see this key if your irman sees it. I have no clue why it beeps though.

I was able to fix this in the hardware settings for IRman. The IR Speed was too fast.

[Snakebite]

The commands that you trigger from an action plugin with a postmessage will not adhere to the anti-repeat. Which is the way it is supposed to be. Only events generated by a hardware plugin will go through the anti repeat check.

Please give more information on the exact problem.

I'm not sure what more information I can give. It only happens in my longest multigroup which involves my plugin. If I press real quick it executes once, if I hold slightly longer, it will execute twice despite a long antirepeat. I have tried to reproduce it for you outside PowerDVD, but had no luck yet. It's not a huge problem, I can press quickly. :) I'll look into it more another day.

[Snakebite]

Ron, you have a somewhat urgent update in your mailbox.