| Main > Software Forum |
| MameWah Technical Thread (for MinWah) |
| (1/4) > >> |
| headkaze:
This thread is really for MinWah, as a technical discussion about MameWah, namely the launching of shortcuts and programs. I have had experience in this field, so I am hoping to give some (hopefully) helpful tips on making MameWah an even better front end. The motive is that I wish to use this as my front end for a cabinet I am currently building, so I would like some specific changes made to suit my needs. I hope this will help create a better front end for everyone. I have coding experience in both C and VB, but as C is my primary and preffered language I have converted alot of code over to VB to help make certain features a reality. I have also attached a VB example project that demonstrates how these features can be applied. So I hope MinWah reads this! New features demonstrated and requested: - Launching MameWah main window from Sub Main instead of a form. Creating an API window instead of using a form allows for better control. Also doing it this way means we can have access to functions like the AddressOf operator which is only available inside a module. - Better launching of lnk's (shortcuts) using ShellExecuteEx so that command line parameters are processed properly. - Better way of launching executables using CreateProcess. It's better than Shell() IMHO. - These allow for more control over the application launched. It will allow us to set the process priority, send keys to the application upon launch, simulate a click on a menu, and change various ways the window's application is displayed like removing the border and menu bar, making it fullscreen or moving the cursor off the screen. - This will also allow the program to force the launched application to the front of the screen. No more hiding windows. - There is also provisions here to write to the process memory space. This could be used for cheats and the like. - Currently MameWah removes the cursor by loading an invisible one. This can cause problems while running other applications, the cursor will dissapear and re-appear. The code I demonstrate will only hide the cursor in the MameWah main screen. - Pressing + or - on the keypad will increase or decrease the global volume. Hopefully MinWah can adapt this to use the second joystick as volume control. - I started writing an adaptation using a DLL to hook all windows messages of the launched application. This would allow one to set up, for example, the ESC key to exit any application. Unfortunately I couldn't get it to work in VB. Perhaps I will work on this more if MinWah is interested. I think that covers just about everything in the demo. When you launch the demo app, keys 1 to 4 on the main keyboard will show demonstrations of launching notepad.exe and shortcuts to notepad.exe and explorer.exe. Pressing the + and - keys on the keypad will turn the global volume up and down. This application is meant for MinWah and him only, there is no point in other people downloading this (except if you are a programmer or just plain interested in this crap). Thanks for your time, and I hope MinWah will reply and comment on the demo. VBLaunch.zip |
| Minwah:
Thanks for the suggestions. I haven't looked at your app yet so bear with me...these are my initial thoughts: --- Quote from: headkaze on November 02, 2005, 05:52:49 am ---- Launching MameWah main window from Sub Main instead of a form. Creating an API window instead of using a form allows for better control. Also doing it this way means we can have access to functions like the AddressOf operator which is only available inside a module. --- End quote --- I use a Sub Main but I am not sure about using API Windows. Could you explain more please, such as what AddressOf is used for? --- Quote ---- Better launching of lnk's (shortcuts) using ShellExecuteEx so that command line parameters are processed properly. --- End quote --- I looked into this a while back when I started working on the current betas. The problem is that ShellExecute will not wait for the shelled app to finish - this is crucial in a FE (I mentioned this in another thread yesterday). I couldn't find a way to ShellExecute & Wait so I opted for sticking with the current launching method. If you know how to do this then I can substitute something in. --- Quote ---- Better way of launching executables using CreateProcess. It's better than Shell() IMHO. --- End quote --- I already use CreateProcess (always have). I recently added Shell as an alternative only if the {nowait} flag is used. --- Quote ---- These allow for more control over the application launched. It will allow us to set the process priority, send keys to the application upon launch, simulate a click on a menu, and change various ways the window's application is displayed like removing the border and menu bar, making it fullscreen or moving the cursor off the screen. --- End quote --- I haven't really played about with this much - I'd be interested in some of this though. In theory you can already launch something maximised ({max} flag) or minimised ({min} flag) but it depends somewhat on the application. The other stuff I don't know much about, although I did attempt to send keys to the application before, but didn't have a lot of joy. --- Quote ---- This will also allow the program to force the launched application to the front of the screen. No more hiding windows. --- End quote --- This should already happen really. The hiding of Windows is done 'just to be sure'. In Windows it is almost impossible IMO to prevent every single thing like the occasional desktop popup - hiding Windows is a good failsafe. --- Quote ---- There is also provisions here to write to the process memory space. This could be used for cheats and the like. --- End quote --- This is probably beyond me to be honest. --- Quote ---- Currently MameWah removes the cursor by loading an invisible one. This can cause problems while running other applications, the cursor will dissapear and re-appear. The code I demonstrate will only hide the cursor in the MameWah main screen. --- End quote --- Actually this is the exact opposite of what happens. I used to just hide the cursor in Mamewah but it caused the exact problem you described - the cursor would pop up when launching emulators etc. Hiding the cursor completely by swapping it for an invisible one means you never ever see it - seems strange if you do see the cursor, it shouldn't be possible. --- Quote ---- Pressing + or - on the keypad will increase or decrease the global volume. Hopefully MinWah can adapt this to use the second joystick as volume control. --- End quote --- I was intending to add a volume control (JCrouse has been on at me about it for ages!). The Player 2 joystick is used for navigation tho, so I would probably add a menu option by default - you can always use the ctrlr feature to remap. --- Quote ---- I started writing an adaptation using a DLL to hook all windows messages of the launched application. This would allow one to set up, for example, the ESC key to exit any application. Unfortunately I couldn't get it to work in VB. Perhaps I will work on this more if MinWah is interested. --- End quote --- Sounds good...I did some reading into hooks but never really got very far. I'm not sure what the limitations of VB are in this respect. --- Quote ---I think that covers just about everything in the demo. --- End quote --- Just about to try it... |
| headkaze:
--- Quote ---I use a Sub Main but I am not sure about using API Windows. Could you explain more please, such as what AddressOf is used for? --- End quote --- Ok nice to know your using this method. Using an API Window is demo'ed in the example app. The AddressOf operator is used to enumerate the windows so you can get a handle to the window. With a handle you can do alot more with the opened application. --- Quote ---I looked into this a while back when I started working on the current betas. The problem is that ShellExecute will not wait for the shelled app to finish - this is crucial in a FE (I mentioned this in another thread yesterday). I couldn't find a way to ShellExecute & Wait so I opted for sticking with the current launching method. If you know how to do this then I can substitute something in. --- End quote --- Again in the example you can see how you can wait properly for the application to finish. It's generally required to specify a "titlebar" string to find the right window. But ShellExecuteEx, as you say, dosn't return a handle to the process, so I use a trick to get it (only works with .exe's so pretty useless) or just search for the titlebar. --- Quote ---This should already happen really. The hiding of Windows is done 'just to be sure'. In Windows it is almost impossible IMO to prevent every single thing like the occasional desktop popup - hiding Windows is a good failsafe. --- End quote --- Oops I meant "hiding a window", not hiding Windows. I just mean the code for bringing a window to front zorder and foreground. --- Quote ---This is probably beyond me to be honest. --- End quote --- Well, there is code to do exactly that, but finding the memory locations etc. will be up to other enthusiastic hackers ;) --- Quote ---Actually this is the exact opposite of what happens. I used to just hide the cursor in Mamewah but it caused the exact problem you described - the cursor would pop up when launching emulators etc. Hiding the cursor completely by swapping it for an invisible one means you never ever see it - seems strange if you do see the cursor, it shouldn't be possible. --- End quote --- I've personally had a few problems with it.. my suggestion is to force the cursor to the bottom right corner of the screen, that way you can still use it if need be --- Quote ---I was intending to add a volume control (JCrouse has been on at me about it for ages!). The Player 2 joystick is used for navigation tho, so I would probably add a menu option by default - you can always use the ctrlr feature to remap. --- End quote --- hehe yes I believe it's an important inclusion since we don't want to wake up the neighbours in crazy hours of the morn' right? Well it just seemed like a cool thing to add IMHO --- Quote ---Sounds good...I did some reading into hooks but never really got very far. I'm not sure what the limitations of VB are in this respect. --- End quote --- Yeah the DLL hook is quite possible, I have working code in C, in fact the DLL is written in C and VB loads the DLL using the LoadLibrary API function. Problem is, I couldn't get it to work in VB (yet). It will be nice to add the ability to quit anything with a key specified by the user. --- Quote ---Just about to try it... --- End quote --- C00l :) |
| Minwah:
--- Quote from: headkaze on November 02, 2005, 08:47:53 am ---Ok nice to know your using this method. Using an API Window is demo'ed in the example app. The AddressOf operator is used to enumerate the windows so you can get a handle to the window. With a handle you can do alot more with the opened application. --- End quote --- The API Window looks like it works pretty well. However is there any practical advantage over the current method I use? --- Quote ---Again in the example you can see how you can wait properly for the application to finish. It's generally required to specify a "titlebar" string to find the right window. But ShellExecuteEx, as you say, dosn't return a handle to the process, so I use a trick to get it (only works with .exe's so pretty useless) or just search for the titlebar. --- End quote --- In your example the problem is present where the program continues after launching the shortcut target (rather than waiting for it to finish). Are you saying the program shouldn't do this, or that it could be modified to fix this? --- Quote ---I've personally had a few problems with it.. my suggestion is to force the cursor to the bottom right corner of the screen, that way you can still use it if need be --- End quote --- What problems have you had (& on what OS)? Since the cursor is changed on a system level you should never see it, unless the cursor is something other than 'arrow'. 'hourglass' or 'arrow+hourglass'. Moving the cursor is no good as some apps move it back to the centre of the screen. I'm pretty confident my current method is best, having spent a lot of time trying different things. --- Quote ---hehe yes I believe it's an important inclusion since we don't want to wake up the neighbours in crazy hours of the morn' right? Well it just seemed like a cool thing to add IMHO --- End quote --- Well a lot of people use a volume knob but a good few people have requested this too. Would you mind if I pinch your code? If not I'll add it for the next beta. --- Quote ---Yeah the DLL hook is quite possible, I have working code in C, in fact the DLL is written in C and VB loads the DLL using the LoadLibrary API function. Problem is, I couldn't get it to work in VB (yet). It will be nice to add the ability to quit anything with a key specified by the user. --- End quote --- That would be pretty cool :) Just a point about the sending of keys...it doesn't seem to work for MAME at least - I suspect it only works with 'Windozy' apps, similarly to how the VB built-in SendKeys function works. Alternatively I could be wrong and it might have been a timing issue, I'll have to do a bit more testing. |
| headkaze:
--- Quote ---The API Window looks like it works pretty well. However is there any practical advantage over the current method I use? --- End quote --- I think so, but without looking at your current code I can't say what the differences are exactly. If you use Sub Main then I wonder how you create your window.. are you using a form? If you are, I am totally convinced that my method is better. Without experience in C it's hard to explain the advantages other than saying it's more API friendlier. The point is my application is meant to work like a normal C program would but using VB. I know the advantages of using VB too since I've programed for a a few years, but C is the way to go. I'm not about to write my own C front end though because I don't have the time, yours is (almost) perfect for my needs anyways. Hope you eventually see my reasons for the way I do things. --- Quote ---In your example the problem is present where the program continues after launching the shortcut target (rather than waiting for it to finish). Are you saying the program shouldn't do this, or that it could be modified to fix this? --- End quote --- Your saying that my application continues after launching the shortcut? Of course it does, so does MameWah. Are you using WaitForSingleObject(hProcess, INFINITE)? Otherwise how do you wait in the background for the process launched to end? Mine does the same except it waits a while, processes the message system, checks if the process has ended and loops. Its basically the same, and designed to take very little processor time. --- Quote ---What problems have you had (& on what OS)? Since the cursor is changed on a system level you should never see it, unless the cursor is something other than 'arrow'. 'hourglass' or 'arrow+hourglass'. Moving the cursor is no good as some apps move it back to the centre of the screen. I'm pretty confident my current method is best, having spent a lot of time trying different things. --- End quote --- Well, I think your method should definately not be removed, rather, my method added as an option. Removing the cursor is ok for some apps, moving the cursor would be a better option for some apps I believe. In that case the cursor is still available just out of view (if you grab control of the mouse or trackball, there you go the cursor is there. --- Quote ---Well a lot of people use a volume knob but a good few people have requested this too. Would you mind if I pinch your code? If not I'll add it for the next beta. --- End quote --- Of course you can use the code.. well the volume code isn't mine, but do you see a copyright notice/terms of use on it? No, neither do I, meaning its freely distributable. The code in mMain.bas is practically all mine. Well, we would be liers saying we didn't get help from code off the net wouldn't we? All the same, I do respect a copyright/terms of use when I see one. --- Quote ---That would be pretty cool Just a point about the sending of keys...it doesn't seem to work for MAME at least - I suspect it only works with 'Windozy' apps, similarly to how the VB built-in SendKeys function works. Alternatively I could be wrong and it might have been a timing issue, I'll have to do a bit more testing. --- End quote --- Well, Mame is a command line application, therefore how do you get the handle to the window? You can't. But I havn't looked at this specifically, perhaps the command prompt window can be accessed and the keys send to that. You know what I'm thinking arn't you? "remove that damn warning message to type ok or move the joystick" hehe, its possible I believe. Thanks for checking out my ideas, I hope they may help in some way. Keep in touch, I think we can work together on some of this :) |
| Navigation |
| Message Index |
| Next page |