Main > Software Forum

LEDWiz SDK v1.3 Released for developers

<< < (5/6) > >>

headkaze:
Has the ocx been updated to support 49 levels of intensity yet? I very much doubt the ocx will be updated after that. All the basic functions required to communicate with the LEDWiz are in the dll, unless Randy decides to update the ROM and add more features but I doubt that will happen since what is done with the LEDWiz is really up to the developers who write the software to control it.

Personally I would go with the dll and forget about the ocx. If you write a wrapper for the dll that has all the functions of the ocx then if worse comes to worse you can always replace it back with the ocx routines. It's not hard writing your own code for things like setting the state or intensity of a single LED (like the ocx does I believe). If you have arrays that keep track of the LED's then this can all be custom written for the dll.

EDIT: BTW No reply from MikeQ :( Perhaps he really has left the scene now?

Howard_Casto:
The real pain about the ocx is when it's updated.  Two versions of the ocx can't live happily together, so if you download an app that uses version 3.0  ALL your apps have to use version 3.0.  So if your favorite app isn't updated (like j5 was and I didn't know about it, unfortunately) you are screwed. 

We definately need to put the buffers inside the dll so multiple devices can access it (in theory at least) and turn on/off individiual lights without interfering with each other.

I'm not fond of the ocx at all and I would have  switched ages ago, if not for that unintentional "feature".

Cameronj:
Thanks so much for this! It is just in time for my star ceiling theater project. :applaud:

RandyT:
It sounds like what needs to be done is a server app, based on MikeQ's DLL or whatever, which tracks the states of the inputs and can communicate with multiple clients.  The server can be a canned executable and the clients can be a DLL (or OCX) of their own, which can be built into a user program.

I'm not sure I am up to this task myself.  I might be able to find some code snippets on the web to help get part of the way there, but client/server apps are not something I have  a lot of experience with.

If someone is good at doing this type of thing, and is seriously interested in helping out, I'll pony up the hardware for the effort.

On another note, Howard, if two programs use 2 different OCX versions and both of those versions exist on the machine, do both programs not continue to work?  I may be mistaken, but does windows not look for the ocx in the folder of the executable before looking for it in the system folders?  An OCX could also be created as a completely new OCX with identical functionality to avoid any potential conflicts.  Of course, older software would still need to be re-compiled to be used with the new OCX, but nothing should break if it's not.  Or am I missing something?

RandyT

youki:
An a new version of OCX can work with programs that are done to use an old version.

It just depends how you made the new version.

If on the new version you didn't change existing method name and parameter.  (but you can add new method, and modify the code of existing one, just don't change the existing interface)

AND  if when you compiled your OCX  you didn't ask to generate a new ClassID  , it will work.

If you register the OCX, it will take the place of the other in the registry , and all your programs will use the new one without any problem.

But if you changed the ClassID , it will be considered as a new OCX and old application will still looking for the old one.

(If i remember well  , the fact to change the ClassID or not , is a compilation option in VB6)



Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version