Main > Software Forum

If you would like to build multi LED-Wiz support into your software...

(1/9) > >>

RandyT:

See this thread.

Thanks,
RandyT

RandyT:
*Cross posted - Mods feel free to delete whichever is felt to be inappropriate*

Whew, this took longer than anticipated.  Decided to add a couple of extra commands and make some proper documentation.

The documentation can be viewed by clicking here (Acrobat Reader required)

The package has been sent to those who first requested it.  If I missed anyone, please let me know.

BTW, the license agreement is basically boiler plate to protect against malicious use of the hardware/software.  Anyone in  this community who wishes to use / re-distribute the control as part of their application(s) can pretty much consider it "rubber stamped" as approved.

Thanks,
RandyT

Howard_Casto:
Looks good thanks..... Something that seems absent from your ocx is the ability to read states as well as write them.  Since it's faster to set all the states and intensities at once, it would be nice if you could check to see if any other programs have messed with the lights and use those vlaues on any lights that are on.  A good example of this would be a keyboard hook to link the mame coin lights (keyboard leds) to buttons.  Now obviously you just turn those three on individually, but if there is another program doing something with the rest of your lights in the background, you want to be able to keep it from interfering with the coin lights. 


Btw.... I know you'll get mad when I say this, but you really need to stop pushing the clipboard method and start pushing the ocx.  Since I've been so negative about the option I wanted to be fair, so that was the first thing I tried when I got the product.  To be blunt it doesn't work.  First you have to turn on a light with one command, and the you have to set the intensity right?  Well if you send two commands without delay, only the last command takes.  You have to set a fairly huge dealy of 200ms for it to take in a reliable fashion. That is if you are using the command line tool.  If you use direct access to the clipboard it doesn't work at all.  I looked up the issue at msdn and it said if two seperate programs try to access the clipboard at the exact same time they both error out and neither command gets accepted.  Since the ledwiz resident app constantly gets the text of the keyboard and whatever app is communicating is constantly setting the text of the clipboard it only stands to reason that eventually the two will hit each other and error out.  It might just be unique to my system, but it errored out farily regularly for me, making it unstable.  Spent two days messing with the clipboard method and never got it to work reliably. 


Now in contrast, I downloaded the ocx from the ledwiz thread.  Had it up and running in 10 minutes and I can get a 3 ms response time for commands, which is more than acceptable.  Been getting it to do all kinds of crazy things since then, that nobody has thought of yet, I'll release a demo of the goofy stuff I'm getting it to do later. 


Anyway, my point is the hardware is very good, but the clipboard method doesn't make things easier, rather it makes things harder.  The ocx is very easy for anyone using a visual studio language to use and it works very well... for that matter your device shows up as HID so if you released some specs about the data transmission, we could access it directly.  Just a thought.  My suggestion for you is to ditch the command line tool you currently include and make a new one the uses the ocx rather than the clipboard.  This way even the non-visual studio programmers have something fairly quick and easy to use. 


Thanks for the work on the new ocx....Once J5 has ledwiz support fully implemented I'll hand it over to my minions and see how it works for them.  :)

RandyT:

--- Quote from: Howard_Casto on July 28, 2006, 02:12:21 pm ---Looks good thanks..... Something that seems absent from your ocx is the ability to read states as well as write them.  Since it's faster to set all the states and intensities at once, it would be nice if you could check to see if any other programs have messed with the lights and use those vlaues on any lights that are on.  A good example of this would be a keyboard hook to link the mame coin lights (keyboard leds) to buttons.  Now obviously you just turn those three on individually, but if there is another program doing something with the rest of your lights in the background, you want to be able to keep it from interfering with the coin lights. 

--- End quote ---

You are welcome.  But I don't think I'll be able to provide what you are asking for.  The parser tracks all of the settings of the outputs, but I'm not sure how I might go about making that info available to another program using a completely different instance of the control.  It would probably make more sense to add the keyboard LED emulation code to the OCX and allow developers to decide whether to use it or not. 


--- Quote ---Btw.... I know you'll get mad when I say this, but you really need to stop pushing the clipboard method and start pushing the ocx.  Since I've been so negative about the option I wanted to be fair, so that was the first thing I tried when I got the product.  To be blunt it doesn't work.  First you have to turn on a light with one command, and the you have to set the intensity right?  Well if you send two commands without delay, only the last command takes.  You have to set a fairly huge dealy of 200ms for it to take in a reliable fashion. That is if you are using the command line tool.  If you use direct access to the clipboard it doesn't work at all.  I looked up the issue at msdn and it said if two seperate programs try to access the clipboard at the exact same time they both error out and neither command gets accepted.  Since the ledwiz resident app constantly gets the text of the keyboard and whatever app is communicating is constantly setting the text of the clipboard it only stands to reason that eventually the two will hit each other and error out.  It might just be unique to my system, but it errored out farily regularly for me, making it unstable.  Spent two days messing with the clipboard method and never got it to work reliably. 

--- End quote ---

Howard, you should really listen and try to understand my stance on this  :banghead:

1: There was no ActiveX control when the LED-Wiz was first released.  I didn't even know how to write one at that time.

2: Not everyone can use an ActiveX control.

3: Not everyone can program, but can probably write a command line for an application in order to turn on some lights.

4: The clipboard method was provided as a means for a user to "hit the go button" for playback of animations they created with the editor.  It was never intended to be the mechanism that actually did the work of playing them.   The clipboard is only polled 10 times a second by the resident software.

5: To reliably use the clipboard method for relatively fast manipulation of the outputs, one has to use error checking when accessing the clipboard.  You are right that 2 applications attempting to write to the clipboard will cancel each other out, but that act raises an error condition that can be trapped.  In that event, the software should simply re-try.  To my knowledge, reading from the clipboard has no such problems.  You also need to have your application watch the clipboard and not attempt to send another command to it until the previous one has been cleared by the resident software.  It's a very rudimentary protocol, but it needs to be followed closely if you intend to push the limits.  I know It works, as I tested it rather completely before ever releasing it.  I ran into the same problems you described and I overcame them.  It's how I know the information above.  Others have also been able to use it effectively.

6: I am not now, nor have I ever "pushed" the use of the clipboard method over the more direct capabilities offered by the ActiveX control.  It would be stupid to do so.  But, the clipboard method does have advantages.  It offers non-programmers or programmers who do not use the "visual studio" languages a means to control the hardware where otherwise, no method would exist.  I've also never stated that it was "easier" to use the clipboard method.  But one thing I will tell you; if it's your only option, it's easier than buying and learning a visual studio language just to turn on a few lights! :)


--- Quote ---My suggestion for you is to ditch the command line tool you currently include and make a new one the uses the ocx rather than the clipboard.  This way even the non-visual studio programmers have something fairly quick and easy to use. 

--- End quote ---

The problem with this is that the control scans for the presence of 16 LED-Wiz devices at startup and initializes the ones it finds.  This causes a very short, but nonetheless noticeable delay at first run.  If it is just left running in the background, you still need to talk to it somehow, and that method would need to be universally available (like the clipboard is).  If you have suggestions for how this mechanism should work, please forward it to me and I will look into implementing it.


--- Quote ---Thanks for the work on the new ocx....Once J5 has ledwiz support fully implemented I'll hand it over to my minions and see how it works for them.  :)

--- End quote ---

No problem.  I can't wait to see what everyone does with it.

RandyT

Space Fractal:
Why not to use a dll instead of clipboard?

Personly I have allways used dll

Navigation

[0] Message Index

[#] Next page

Go to full version