Sorry man but you couldn't be more wrong.
J5 can do attract mode sequences, for example. It just does them a different way. You set up the default state for all the lights, which cna be multiple states in sequence. J5 IS a resident app, it's just optional because it uses some memory and some people don't like that.
ledwiz does have a delay. There's even a checkbox to turn if off (or down) in powermame. It has nothng to do with the connection method, from what I understand it's some sort of usb chipset issue. Yes the ocx is significantly slower than the dll, but the dll stil can't instantly light something.
Your point about windows apis vs external dlls is invalid. When m$ makes a dll update, they make sure it is backwards compatable, third-party dlls, not so much. You don't have to worry about dlls that you are calling via the api because they are installed by default with windows. The only non-windows api calls I ever make are to directX, because, well if you are running mame without directx then god help you. The whole reason the api layer was invented was so that developers don't have to package their stuff up with dozens or dlls and manage their registration, thus bloating and complicating the project. And I did do multi-threading in vb6 remember? I already had a working hooking app before you helped me with the variable issues, it just didn't get the name properly. But to answer your question, when I find something that vb6 can't do, I don't do it. Of course over the past 10 years or so there's only been maybe 2 or 3 things that I've needed to do in vb but couldn't. There's a flaw in your thinking there about the dlls. If I was constantly writing C++ dlls to get things done then I just code the whole thing in C.
You are confusing the issue of can with should. Can you make a fe infinately more complex by doing all the coding requried to properly light all the buttons and properly assign all the labels? Of course. Should you? Well if your fe is perfect and you never want to add another new feature then you probably have the time as a developer to do that, otherwise you'll be spending all of your time getting this feature integrated. As of now only two applications assign labels and lights properly... j5 and powermame. (And to be honest I'm not sure about powermame and labels, but I'm giving it the benefit of the doubt.) It was easier in powermame because you don't have to recall data, it's in there already. J5, on the other hand has a hard time doing it. Getting all the data required to do this accurately and properly takes at least one call to mame and the parsing of up to 5 very large xml files as well as the controls.xml/controls.ini. Some of the other stuff can be stream-lined by a more telented programmer I'm sure, but the mame call can't be avoided. You can either do it per-game, which makes quick changes impractical, or all at startup, which would make your boot-time significantly longer. I'm not the best programer in the world so I'm sure some speed improvement can be made, but not enough to make it practical to, lets say have the layout change on the fly while you are scrolling through the list to reflect the current game selected. It can be done AFTER you stop of course, but at that point speed isn't a issue and you can just set it externally. And before you start mentioning this fe and this app that does it quicker, yes I'm aware of many of them, but unfortuantely they do it wrong. They output a rough reflection of what the layout should be, their accuracy is generally around 60% because they don't read the cfg, ctrlr, driver and device settings like I do. And I understand that for a lot of people that this rough estimation is enough, but I said right in my first sentence in that post in the last post that this is what I thought. I don't think you should do something if you aren't going to do it right.
And I want to make something prefectly clear, I'm not being arrogant about this, this is just the truth. The reason j5 is so accurate is because I abandoned all of my other projects indefinately as I built the complex backend for it. And guess what? About the time I got it done, they up and changed mame's file system structure and I had to do it all over again! Dk hasn't been updated in almost 2 YEARS. That should tell you what a full time job it is to keep the stupid thing maintained. It isn't the most accurate and feature driven because I'm god's gift to programming, it's that way because I spend way more time on it than any normal person would. So that goes back to what I was saying earlier, while you can do it in the fe, it'd be a full-time job to implement.
Yeah your right, I suppose you couldn't have your buttons "talk" to you ro anything crazy like that if you did it externally. Maybe I'm having a lapse in logic or something, but why would you want to do that inside a fe in the first place? At least some of the buttons on your layout are used for actual navigation in the fe, so it's impossible to press them all without launching a game or scrolling through the list inadvertantly. Aside from that, this seems like a feature that would only be useful while playing a game. Again, I might be missing something.
Yes you are absolutely right, you can't have a dynamically-generated "scrolling sequence" via command line. Again though, unless my logic fails me you can't have that even if it's integrated. I don't know what the scroll speed is on the average fe is these days, but in my fe the time between transition from one game to another is less than 10 ms. Yeah you could have em blink as you scroll or something but it'd be so fast that it'd give you a seizure or something.
Now if you are referring to loading a different animation while scrolling that isn't keyed to the scroll speed, then you can do taht via external calls. Send the scroll animation layout file when starting a scroll, and set it back again when idle.
And I'm not being sarcastic at all but your going to have to explain that last line. Given what I've said about how a lot of the things you suggested are impractical to do what cool things are left that you can only do via integration?
You seem to be upset or something and I don't get that. You asked my opinion about the app and in order to give it, I had to explain why integration is a bad idea. You can't exactly get upset because I gave you my opinion when you asked me for it. If you wanted me to lie then you should have said so.
I think you aren't getting what I was saying about the windows messaging being slow though. There is some delay (not much, but time is taken) when you send or recieve a message. It isnt huge at all but it causes issues because windows message threads are cached and there isn't any practical way to do a "frameskip" to ignore incoming message processing while you are setting the lights.
You know that bug in basketball I mentioned the other day? That's the perfect example. See it's flashing so fast that I "miss" some commands while I set the lights. The problem is they aren't "missed" they are waiting in the window's built-in message que building up as they are waiting to be processed. Eventually the load is just too great. If I manage to exit out of basketball before the build-up crashes the app it continues to blink on and off even after mame has exited for up to a full minute. This isn't something I've coded that is making that cache, it's the way windows works so there is no getting around it. The only way to solve this issue is to have two-way communication, but that kills your speed advantage right there. For just setting layouts, yes messaging would work great. For on the fly animation, it could be dangerious.
You are missing a much easier way to get things done though if you just really want to use messages. We made the sdk right? I'm writing this app that can do all kinds of things besides just ledwiz via the sdk right? They use messaging right? Ok, time's up, pencils down. Instead of making a new message protocol and going to the trouble of writing an app that only handles the ledwiz, why not just write a dll everyone can use that "fakes" mame's output system? Mame doesn't do anything special, it just sends it's hwnd and sends a set of custom messages, so an app doesn't have to be mame to take advantage of a sdk app. Then a developer has access to anything coded via the sdk. Heck if there's some feature missing from the little app I'm coding just add them and then you have an app that does everything you wanted plus it has all kinds of other crazy interfaces supported.
We are very fortunate with mame because inputs aren't changed quickly for the most part. The few that are changed quickly are thankfully force-feedback-style effects and m$'s force feedback interface is so quick that time is measured not in milliseconds, but in microseconds. So hopefully we aren't going to run into the issue there.
Ok man take a breath, it's all going to be alright.