It's really easy to support ini files in VB6 using WritePrivateProfileString() and GetPrivateProfileString() API functions. So for simple reading/writing settings it's ideal. There is probably a module that does this on the Net somewhere.
Even easier than that if I choose to put them in the registry. But it'll probably be a simple data file that lives where the app lives. Something like what the KeyWiz Uploader2 software does.
My only complaint (hey I'm a GGG customer now I have a right to complain! hehe) is the issues with ocx/dll conflicting with multiple applications. For your application to work the other one has to be shutdown.
Heh. You can complain, but this software is free to all LED-Wiz users and was never promised as part of its function. It's literally tantamount to your car dealer calling you a year after you bought the car to tell you he has a free stereo for you. So feel free....
I don't know if what you are talking about above really matters though. Why would they conflict? Each application can open a new handle to the device and communicate with it through that handle. If both are trying to send data to the unit at the same time, it's going to be a pointless endeavor regardless. The LuminAudio Engine literally streams data to the device when in use and anything an FE did would be changed by it immediately. If the engine is not active, there should be no conflicts. So what you really need is a way to disable it and then re-enable it at will, which you pretty much would already have if you selectively launched and then "killed" the application as needed.
Can I convince you to write a dll for this? So the actual beat detection is separated from the LEDWiz stuff so I can import it and use it in my own plugin? The number of hours I wasted analysing beat detection algorithms makes me appreciate the work you must have put into this. But without it in dll form it's really limited to run as a stand-alone app. Supporting other programmers to write software for the LEDWiz is really a good business move when you think about it.
No. The routines are tied specifically to the capabilities of the LED-Wiz, and the hundred+ hours I put into it are a
gift to my LED-Wiz customers. As for what is good for "business", that's a topic of discussion for a different thread or private conversation.
For now though a simple addition of a -hide command line option or something to not open the form, or even better minimize the app to the taskbar with an icon in the tray.
The app will eventually be able to be minimized to the taskbar. If you noticed, I literally posted 4 versions of the software within a weeks time. They were going up as fast as I had a new function stable because I wanted the functionality into my users' hands. Now that I feel that part has been fairly well accomplished, I'm going to take a step back and consider a few things on the housekeeping side of things.
I asked about the target audience because the majority of users with cabs will have the conflict issue I mentioned in the second paragraph. As it is this app would work well for pure jukebox based cabs but if you have a Swiss army knife type cab it is both arcade and jukebox.
I'm not completely convinced that this "conflict" issue exists (see what I wrote earlier) What happens when you attempt to use your software with this running in the background (i.e. output disabled)?
I have a "Swiss Army" knife type cab, as I think most of us do. Having this utility running in the background, that allows me to turn it off when I don't want the lights flashing, seems like it works fine. But if there are true issues like the ones you talked about, then tell me what they are and how to reproduce them. Maybe there is another way to deal with them that will satisfy the goals of all involved.
RandyT