Zalman HD135 VFD (VlSys Mplay) (2 Viewers)

[cybrmage]

Here is an updated version.

It should fix all the issues that have been pointed out by -Manfred- and Herr R aus B.

As far as the "?" characters on the display, that would be the displays way of telling you that it has received a character that it does not support. The easiest way to fix it is to configure MediaPortal (in configuration under General/Skin/Display Language) to use English. An alternate way to "fix" the problem is to configure character translation for the ExternalDisplay plugin.

To set up translation, load the ExternalDisplay.xml file in a text editor. Near the bottom of the file you will find a two sections named "TranslateFrom" and "TranslateTo":

Example:
<TranslateFrom>
  <string>x</string>
  <string>y</string>
</TranslateFrom>
<TranslateTo>
  <string>a</string>
  <string>b</string>
</TranslateTo>

This will convert all instances of "x" to "a" and "y" to "b".

Add a string section to each section for every character that will not display on the VFD.


As far as advanced features.... You are pretty much on your own... I don't have the device, and "advanced" features would be far beyond what I'd be willing to do without having the hardware on hand....

Regards,
CybrMage

 

[aXs]

Good job cybrmage everything is working correctly. That's perfect. Thanks a lot

And of course thanks to all the people who work on this problem.

 

[-Manfred-]

Hmm... I'm lost now. Every time getting this error now no matter what driver used. Any ideas except change from Vista to XP?

2007-12-30 19:17:22.447355 [ERROR][ExternalDisplay]: VLSYS_Mplay.Initialize(): CAUGHT EXCEPTION while opening port COM3 - System.UnauthorizedAccessException: Access to the port 'COM3' is denied.

/m

 

[cybrmage]

Every time getting this error now no matter what driver used.

Try a reboot... The Vista comm port subsystem may be locked...

Check device manager... If you have rebooted lately, the port may have changed ( I have a MatrixOrbital MX2 display that like to change from COM4 to COM2 every so often when rebooted).

Post logs... Although I have attempted to make sure the port is always closed during setup and configuration, I may have missed something...

Regards,
CybrMage

 

[cml11]

M.Play restore

Hello, I built PC with MediaPortal to HD135 case, so big thanks for this plugin. I've only one question. Is there some way to detect presence of M.play software when MP starts, automated close/deactivation of it for plugin use, and restore it's before state when MP closes? Thx

 

[Herr R aus B]

It should fix all the issues that have been pointed out by -Manfred- and Herr R aus B.

Unfortunately it doesn't - I still have the same problem with the configuration. Clicking the "advanced" button in the configuration dialogue flashes the remote mapping dialogue once and gives me the red exclamation mark. Pressing the button for the second time then shows the remote mapping dialogue. Returning from this dialogue i still have the red exclamation mark and the "OK" button in the configuration dialogue remains disabled. Although the modified mapping is saved now.

The driver DLL is still locked after closing the configuration application and the process is still running (as described above)

Is this maybe an X64 issue as 64 bit windows is not officially supported?

As far as the "?" characters on the display, that would be the displays way of telling you that it has received a
[...]

Add a string section to each section for every character that will not display on the VFD.

I'm gonna try that - thanks for the hint.

As far as advanced features.... You are pretty much on your own... I don't have the device, and "advanced" features would be far beyond what I'd be willing to do without having the hardware on hand....

That was rather less seriously meant as I can imagine the amount of work implicated. Never the less I am thinking of coding a C++ based service that offers sockets for IRTrans access and display control do you think you might be interested in coding the display driver to access that service *if* I succeed coding it?

There still are some issues left, that might be not so hard to solve. Obviously there is a problem initializing the display. I peeked in your code and the only place where I found initializing stuff was:

commPort.Write(new byte[] { 0xAA, 0xAA }, 0, 2); //Init IR & Display

That's a little bit less than what the MHC software does. Obviously it leads to a different behaviour of the VFD. Using your driver will not initialize the fans - unfortunately they run on a rather high level after switching on (i wonder who designed this hardware...) und that's loud. The other point is, that sending windows to standby switches off the VFD. Thus it's not possible to get windows awake using the remote control. Using the MHC software instead of your driver lets you send windows to standby and one can wake it up with the romte. Now here is, what he MHC software sends to the VFD for initialization:

A4 7D ¤}
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
AA AA ªª
A0
A5 38 ¥8

Must be some "hello are you out there?"

A1 00 A7 57 65 6C 63 6F 6D 65 20 74 6F 20 20 20 ¡.§Welcome to
20 20 20 20 20 20 20 00 .
A2 00 A7 20 20 4D 2E 50 6C 61 79 20 48 6F 6D 65 ¢.§ M.Play Home
20 43 65 6E 74 65 72 00 Center.
AF

This sets the display

AC ¬
00 .
00 .

as far as I tested it this sets the fans to 0% (AC <fan1> <fan2> with 00 = 0%, 47 = 40%, 58 = 50%, 6A = 60%, 7C = 70%, 8E = 80%, 9F = 90%, B1 = 100%)

00 00 00 ...
AD 00 00 10 18 04 00 00 00 00 00 00 00 0C 1B 14 *...............
08 00 00 00 00 06 1B 05 02 00 00 01 03 07 09 00 ................
00 00 00 04 18 10 00 00 00 12 10 14 13 08 04 03 ................
00 09 01 05 19 02 04 18 00 00 09 07 03 01 00 00 ................
00 .

This seems to be important.... I attached the complete communications log and a few more for those who might be interested...

Do you think you can incorporate this in your driver? Or even better give us an opportunity to configure all this hex stuff ourselves? Maybe something like an XML file with several sections like Init1, Init2, FanSetup, etc...? That might help finding the exact initialization sequences without keeping on bothering you

Finally there is an issue with key press repeats. The M-Play remote is somewhat strange. As you can see in the PDF with the remote codes I posted some days ago, I always added a "7E" because i thought it belonged to the key code. Now somewhere here in the forum I read, that the "7E" just means "repeat the last key". Would it be possible to evalute that behavior in the driver?

Greets

Axel

 

[cybrmage]

Clicking the "advanced" button in the configuration dialogue flashes the remote mapping dialogue once and gives me the red exclamation mark.

I was FINALLY able to duplicate this... I think I have it fixed this time.

The driver DLL is still locked after closing the configuration application and the process is still running (as described above)

Is this maybe an X64 issue as 64 bit windows is not officially supported?

I can't duplicate this condition.
It may be an X64 issue, but I can't be certain. Does configuration still hang if you Disable the ExternalDisplay plugin?

When it hangs, let it sit for a minute then copy the configuration.log and post it. (IE: make a copy of the configuration.log before you forcably shut down the process)

Never the less I am thinking of coding a C++ based service that offers sockets for IRTrans access and display control do you think you might be interested in coding the display driver to access that service *if* I succeed coding it?

Nope. The ExternalDisplay plugin already has an IRTrans driver.

Obviously there is a problem initializing the display.

The { 0xAA, 0xAA } initialization was the only information provided to me...

That's a little bit less than what the MHC software does. Obviously it leads to a different behaviour of the VFD.

Although you seem to have accumulated a large amount of data, it's not all that useful, as most of it only shows a single capture. To be able to determine what is static initialization and what (if any) data is dependant on date or time or option selected, there should be multiple captures... Also... a description of what is shown on the display would be helpful. (What does the sequance { 0xAD, ...., 0x00 } do??? that's a lot of data to "decode" without knowing what options are set or what the display is doing... 8-} )

Using your driver will not initialize the fans

try the new version...

The other point is, that sending windows to standby switches off the VFD.

What happens when you shut down MediaPortal (without putting the machine in standby/hibernate)??? The shutdown code was provided by -Manfred- without explanation or description of what the display does on shutdown.

Remember... I don't have the hardware... so I can't see what any of the commands actually do.... saying that the display doesn't act the way it does with MHC tells me absolutely nothing... I don't know how the display acts under MHC!!

Finally there is an issue with key press repeats.

I didn't find any documentation (official or otherwise) that indicated that the 0x7E code was sent with every button press... But, your log shows that there are indeed two bytes sent for every button press. I have changed the driver to accomodate this behaviour.




Here is the new version:

I have redone the remote mapping file so that the order of the keys in the editor more closely matches the layout on the remote (from top left to bottom right) and changed the name of some keys to better match the button labels (thanks Herr R aus B for providing a readable picture of the remote!).

I have also updated the default button mapping to fix some of the keys so they actually do what they are supposed to do.

The driver will NOT update the existing mapping file (which will still work properly). If you want/need to get the new default mappings, you should delete the VLSYS_Mplay.xml in your MediaPortal's InputDeviceMappings\custom directory.

Also changed is the Advance configuration... The "Advanced" button no longer brings up the remote mapping editor. Instead, it brings up an advanced driver configuration screen.

On the advanced configuration screen you can set some driver specific options. Currently, you can disable the remote control, and you can enable use of the fan controller (experimental).

Regards,
CybrMage

 

[Herr R aus B]

I was FINALLY able to duplicate this... I think I have it fixed this time.

Great - that releases me from the suspicion to be some nerd

I can't duplicate this condition.
It may be an X64 issue, but I can't be certain. Does configuration still hang if you Disable the ExternalDisplay plugin?

When it hangs, let it sit for a minute then copy the configuration.log and post it. (IE: make a copy of the configuration.log before you forcably shut down the process)

I did some testing - the problem is reproducable and obviously not related to your driver. Although I attached two logs - one before and one after killing the process. And there is no diffeence between these logs. That leads me to the assumption, that this 32 bit application closes correctly but is not properly handled by the 64 bit runtime. Anyway - maybe it's also a bug in the configuration utility. But as there's no official support for 64 bit systems yet...

Never the less I am thinking of coding a C++ based service that offers sockets for IRTrans access and display control do you think you might be interested in coding the display driver to access that service *if* I succeed coding it?

Nope. The ExternalDisplay plugin already has an IRTrans driver.

Complete misunderstanding. What I meant was, that I have a windows service in mind, that offers several interfaces (plain pure common and boaring sockets or more sophisticated SOAP based web services to be state of the art). These interfaces would be:

• configuring automatic fan control (on tcp port X, should be configurable)
• reading temperature values and setting fan speeds (on tcp port Y, should be configurable)
• setting display contents (on tcp port Z, should be configurable)
• reading remote codes (probably using the IRTrans protocol on port 21000)

My question was meant like as in would you be interested to write a display driver, that accesses this service instead of accessing the VFD itself. This could also incorporate configuring automatic fan control etc - each as seperate plugins as the service offers several interfaces on different ports. The other benefit would be, that i could provide a VFD simulator this way. This is simply a little bit service oriented way of doing it - just a proposal, though

Obviously there is a problem initializing the display.

The { 0xAA, 0xAA } initialization was the only information provided to me...

This was not meant to be a complaint at all! I just wanted to be helpful

Although you seem to have accumulated a large amount of data, it's not all that useful, as most of it only shows a single capture. To be able to determine what is static initialization and what (if any) data is dependant on date or time or option selected, there should be multiple captures... Also... a description of what is shown on the display would be helpful. (What does the sequance { 0xAD, ...., 0x00 } do??? that's a lot of data to "decode" without knowing what options are set or what the display is doing... 8-} )

Right - i didn't say, that I can reproduce this behaviour. All this, what I posted happens during the MHC shows its (very colorful) splash screen. The first part must be searching for the device, as MHC says it was scanning all the COM ports. Seems just to be the cheap way of shouting to all directions and wait for some answer Then there is one line, I thought it was part of the "where is my COM port" search:

A5 38 ¥8

According to your source code this sets the display's brightness to 100% (whith 25% = 0x3B, 50% = 0x3A, 75% = 0x39, 100% = 0x38). This then always is followd by initilizing the fans according to the AFC settings in the MHC software. Then the display is set to whatever startup message is configured. The most interesting thing is this 41 byte block at the end if the initialization. My guess is, that it sets a bunch of paramters which are - of coruse! - nit documented. I wrote to Zalman, to VL System and I also contacted that guy dero here from the german section of the forum, because he did some testing and wrote some controlling software for this VFD. But I didn't get any response so far. And I doubt, that Zalman or VL System will let private persons peek into their deep secrets I also tried to find out, whether some linux folks already analyzed this VFD - so far no results, but I am sure there will be something sooner or later.

Anyway - these 41 bytes are rather interesting, as such blocks occur here and there with slightly different content. So far I would just try to emulate exactly what I sniffed and to release you from all this impossible testing I thought, it might be a good idea to have the opportunity to specify all this hex code stuff in some configuration file - that would help me to do some testing here using your driver.

Using your driver will not initialize the fans

try the new version...

I did so and I am amazed! Works perfectly - at least it switches off the fans and there is wonderful silence

Now of course it would be great if the driver would be able to set fan speeds (see my above attachments). At the moment, I think, that reading the temperatures is done sending the VFD a 0xAF and get two bytes in return, where the first byte seems to be the second sensor and the second byte the first sensor. At least that is, how the MHC software treats the values.

The other point is, that sending windows to standby switches off the VFD.

What happens when you shut down MediaPortal (without putting the machine in standby/hibernate)??? The shutdown code was provided by -Manfred- without explanation or description of what the display does on shutdown.

Remember... I don't have the hardware... so I can't see what any of the commands actually do.... saying that the display doesn't act the way it does with MHC tells me absolutely nothing... I don't know how the display acts under MHC!!

Again - that was not meant as a complaint! In that earlier post I attached a file showing what MHC writes tp the COM port before sending windows to standby:

00 00 00 ...
AE AE ®®

undocumented stuff...

A1 00 A7 4D 2E 50 6C 61 79 20 48 6F 6D 65 20 43 ¡.§M.Play Home C
65 6E 74 65 72 20 20 00 enter .
A2 00 A7 20 20 20 20 20 20 20 20 53 74 61 6E 64 ¢.§ Stand
62 79 20 4D 6F 64 65 00 by Mode.

setting the display text...

AC 47 47 ¬GG

setting the fans to 40%

A4 7E ¤~
A4 76 ¤v
01 .
11 .
1E .
1F .
01 .
0C .
1D .
0B .
AE ®

undocumented stuff...

A5 3B ¥;

setting the display's brightness to 25%

This matches what I can watch during the process of sending the PC to standby. After this sequence is completed, windows goes to standby and can be woke up using the PwrOff button. And exactly this doesn't work with your driver. That means, pressing the PwrOff button sends the PC to standby, but then you can't wake it up using the remote - no matter what button you press. Hitting the keyboard, moving the mouse or pressing the case's PwrOn/Off button shortly wakes windows up again. My guess would be, that one of the following conditions are true:

• The MHC software somehow listens to what happens on the COM port and wakes up windows, when PwrOff button on the remote is pressed
• The above undocumented byte sequence between setting the display's text and dimming the display to 25% tells the VFD to listen for certain keystrokes and then wake up windows by emulating a short press of the case's PwrOn/Off button - this makes sense, as the VFD is connected between the case's PwrOn/Off button and the motherboard

I tend to think it's the latter, because what application should listen to the COM port when windows is asleep? Especcially after the COM port log also shows, that the MHC software releases the COM port after sending the above sequence:

015813: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0
IOCTL_SERIAL_PURGE: Purge requests
Purge mask=TXABORT: Read requests, RXABORT: Receive buffer

015814: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0
IOCTL_SERIAL_PURGE: Purge requests

015815: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0
IOCTL_SERIAL_SET_WAIT_MASK: Set current event mask
WaitMask=None

015817: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0
IOCTL_SERIAL_SET_WAIT_MASK: Set current event mask

015818: I/O Request (DOWN), 30.12.2007 17:01:29.437 +0.0
IOCTL_SERIAL_PURGE: Purge requests
Purge mask=TXCLEAR: Write requests, RXCLEAR: Write buffer

015819: I/O Request (UP), 30.12.2007 17:01:29.437 +0.0
IOCTL_SERIAL_PURGE: Purge requests

015820: Close Request (DOWN), 30.12.2007 17:01:29.437 +0.0
Buffer size: 0x0 bytes

015821: Close Request (UP), 30.12.2007 17:01:29.546 +0.109
Buffer size: 0x0 bytes
Status: 0x00000000

Finally there is an issue with key press repeats.

I didn't find any documentation (official or otherwise) that indicated that the 0x7E code was sent with every button press... But, your log shows that there are indeed two bytes sent for every button press. I have changed the driver to accomodate this behaviour.

You probably couldn't find any, as this was described in the german section by this dero (see above). Aren't you reading the german posts??? (Kidding!) Anyway, the driver still doesn't react on permanently pressed buttons. What i wrote in that PDF file was insufficent I think, because I thought each key stroke results in two bytes. Somehow, this remote itself is a little bit crappy, because using it over the MHC software, it produces duplicated key strokes. Seem as if the buttons on the remote itself are rather cheap... Anyway - as far as I watched it und that is congruent with what I found, the remote is supposed to work like this:

1D -> DOWN was pressed once

1D 7E 7E 7E 7E 7E 7E 7E -> DOWN was hold and should result in 8 DOWNs (7 repeats)

But it could also be like this:

1D 7E -> DOWN was pressed once

1D 7E 7E 7E 7E 7E 7E 7E -> DOWN was hold and should result in 7 DOWNs (6 repeats)
The latter version seems to be rather illogical. I dunno how you treated the information so far. The result is, that no matter how long a hold a remote button pressed, I get exactly one key stroke. That is, if I need 4 DOWNs I have to hit the Down button 4 times. Anyway - your driver treats the remote signals better than the HMC software as you obviously filter out some of these unwanted duplications produced by this (rather crappy) remote...

Maybe a good solution would be to remeber the last valid remote code and ignore 2 or 3 directly following 0x7E. Then if there are additional 0x7E send the last valid remote code instead. That should result in a behaviour like having a short gap between one button stroke and repeated button strokes... Just a proposal. The problem would be to define what are valid remote codes - maybe thos, defined in the XML file...

Here is the new version:

I have redone the remote mapping file so that the order of the keys in the editor more closely matches the layout on the remote (from top left to bottom right) and changed the name of some keys to better match the button labels (thanks Herr R aus B for providing a readable picture of the remote!).

You are very welcome - as I stated before, I am not complaining but just trying to support your work as much as I can! And I like the new version - especially the fact, that one can disable the remote. This MPlay remote really is a pain in the a****. The remote sensor wouldn't accept most of the remote codes sent ba a generic and programmable remote that controls all my other equipment wothout any problems. Even worse, some of the remote codes of the MPlay remote interfere woth my other devices. Terrifying!

Now with your driver I have the chance to ignore this MHC stuff and the MPlay remote and maybe succeed with using an old Terratec Cynergy USB IR receiver. Maybe that one is able to talk to my generic remote...

Also changed is the Advance configuration... The "Advanced" button no longer brings up the remote mapping editor. Instead, it brings up an advanced driver configuration screen.

On the advanced configuration screen you can set some driver specific options. Currently, you can disable the remote control, and you can enable use of the fan controller (experimental).

Works brilliantly so far!

There still is that german umlaut issue. This definately is no problem with the VFD, as it cn display them perfectly (see attached picture). This is, what MHC sends to the display:

A1 00 A7 20 20 20 20 20 41 75 74 6F 20 55 73 65 ¡.§ Auto Use
72 20 20 20 20 20 20 00 r .
A2 00 A7 20 20 20 20 20 49 6E 64 69 63 61 74 6F ¢.§ Indicato
72 20 20 20 20 20 20 00 r .
A1 00 A7 D6 20 F6 20 DC 20 FC 20 C4 20 E4 20 DF ¡.§Ö ö Ü ü Ä ä ß
20 20 20 20 20 20 20 00 .
A2 00 A7 20 20 20 20 20 20 20 20 20 20 20 20 20 ¢.§
20 20 20 20 20 20 20 00 .

Now as you can see in screenshot of MP with german language defined for the skin, MP displays the umlauts perfectly, but then sends these question marks to the VFD. Here is a log of what your driver writes to the COM port:

00 A7 .§
4D 65 69 6E 65 20 46 69 6C 6D 65 20 20 20 20 20 Meine Filme
20 20 20 20
00 .
00 .
A2 ¢
00 A7 .§
3F 20 3F 20 3F 20 3F 20 3F 20 3F 20 3F 20 20 20 ? ? ? ? ? ? ?
20 20 20 20

Could that maybe be an issue with windows code pages, unicode or whatever transformation within MP?

Once again: I really appreciate your work and please don't take my rather long comments as complaints or nagging or whatever. I am really trying to provide you with as much information as I can as I know that this blind coding you are doing at the moment is rather annoying.

Greetings,

Axel

PS: Just to give you more information - this here is the device we are talking about

 

[Herr R aus B]

Hello, I built PC with MediaPortal to HD135 case, so big thanks for this plugin. I've only one question. Is there some way to detect presence of M.play software when MP starts, automated close/deactivation of it for plugin use, and restore it's before state when MP closes? Thx

what about simply uninjstalling it?

 

[cybrmage]

Great - that releases me from the suspicion to be some nerd

Ummm... NO COMMENT!! 8-}

The first part must be searching for the device, as MHC says it was scanning all the COM ports. Seems just to be the cheap way of shouting to all directions and wait for some answer

Can you provide a snoop on the serial port showing both data sent to the display and data received from the display when the MHC software starts up? It would be nice to know what data is sent back from the display during the initialization.

According to your source code this sets the display's brightness to 100% (whith 25% = 0x3B, 50% = 0x3A, 75% = 0x39, 100% = 0x38).

The brightness should be controllable by setting the contrast slider on the ExternalDisplay configuration screen.

Now of course it would be great if the driver would be able to set fan speeds

Do the fan speed control sliders on the advanced configuration screen not work?

I think, that reading the temperatures is done sending the VFD a 0xAF and get two bytes in return, where the first byte seems to be the second sensor and the second byte the first sensor.

The question is, how do we distinguish between data sent from the display in response to a tempurature request, and data send by the display as the result of a remote button being pressed?

You probably couldn't find any, as this was described in the german section by this dero (see above). Aren't you reading the german posts??? (Kidding!)

Ich weiss nicht lesen oder schreiben Deutsch!!

Anyway - your driver treats the remote signals better than the HMC software as you obviously filter out some of these unwanted duplications produced by this (rather crappy) remote...

All I'm doing right now is ignoring the 0x7E returned with the button code.

From what I could determine from your logs... Each remote button press generates two bytes... the key code and 0x7E. So the question is... does holding down a button result in two bytes of 0x7E, or a single byte of 0x7E after getting the initial two bytes for the button press?

Maybe a good solution would be to remeber the last valid remote code and ignore 2 or 3 directly following 0x7E. Then if there are additional 0x7E send the last valid remote code instead. That should result in a behaviour like having a short gap between one button stroke and repeated button strokes... Just a proposal. The problem would be to define what are valid remote codes - maybe thos, defined in the XML file...

That's probably the best way to handle the "repeat" of remote buttons...

But... I need to know exactly what is sent by the display...

Please install the new driver (I have added increased logging to the received data routines)... Then run mediaportal... The press and hold one button on the remote... then shutdown MediaPortal and post the mediaportal.log. Thanks.

Now with your driver I have the chance to ignore this MHC stuff and the MPlay remote and maybe succeed with using an old Terratec Cynergy USB IR receiver. Maybe that one is able to talk to my generic remote...

Yeah... Good luck with that!!... The IR receivers that come with some TV and Satellite cards are very problematic... many will only work with the remote that they are bundled with.... You are better off with a cheap Microsoft MCE remote bundle (The old version... silver colored remote not the one with a Vista-Only black remote) if you want ease of use.

There still is that german umlaut issue. This definately is no problem with the VFD, as it cn display them perfectly (see attached picture).
.
.
.
Could that maybe be an issue with windows code pages, unicode or whatever transformation within MP?

It could be... The quick test I did indicates that the ExternalDisplay handler is sending the text to the display driver with the umlauts already changed to "?"... I haven't yet found where this translation is taking place... still looking.

Once again: I really appreciate your work and please don't take my rather long comments as complaints or nagging or whatever. I am really trying to provide you with as much information as I can as I know that this blind coding you are doing at the moment is rather annoying.

Your long comments are NOT taken as complaining or nagging... The information presented is very helpful and appreciated... (much better that the usual "the driver doesn't work... fix it" comments that I usually get!)

PS: Just to give you more information - this here is the device we are talking about

The entire "mr" series and some of thier "retail" units all seem to be based on the same basic hardware... So hopefully, this driver will work with all the different versions.


Anyways... here is a new version...

I've added the extra commands to the shutdown procedure and extra logging to the serial receive routine... Hopefully it will give the info needed to get the button repeat to work.

Regards,
CybrMage