I want to make my own Start Menu replacement and I am trying to figure out what approach to use. There are a number of ways the Start Menu is activated: click on it, hit windows key, hit Ctrl+Esc keys or tab until it gets focus and hit the space or enter key.
I know enough about win32 to do each one of these separately and I could figure it out with Spy++. I'd really like to know if there is an easier way through and I can't find any helpful articles.
I'd like to do this for XP and Vista/Windows 7.
I guess that you would have to inject yourself into the explorer.exe process (There can be more than one, but you want the one that has the "Shell_TrayWnd" window) and subclass the taskbar or one of its children to catch/eat the message that brings up the startmenu and instead, show your own window.
Take a look at http://bitbucket.org/wez/evildesk/src/755606d7935d/gdi.cpp , I think you could start your project by seing what they've done.
You can use WindowBlinds and design your own Start Menu as well.
Related
I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.
I need to create a GUI working on windows that can be activated by pressing short cuts.
1. is it possible without setup class?
2. if not possible, just achieve pressing hotkeys and activate my program--how should i code it out--would be enough
thanks (I am using Qt for vs2012 add in to do the GUI)
I put some code up that starts a thread that does this. It is windows specific, but it does the job.
Clipboard Shortcut/Hotkey binding with Qt outside of application
One alternative to all of this, is to go to a shortcut to your program, go to its Properties, and then click on the shortcut area and type your desired shortcut. As long as it doesn't overlap with existing hotkeys that are registered in windows, it should work, without a hidden presence of your app in the system tray or some other background thread.
Hope that helps.
libqxt offers a QxtGlobalShortcut class that does what you want.
I'm trying to build an terminal application that, when started, will take the user away from their prompt and present them with a screen with an interactive menu. I would like the user to be able to interact with it in the following way:
They will start the application by running my_app from the terminal. This will start the application and present them with the root menu.
They will use the cursor keys to navigate around the menu and use the [ENTER] key to make a selection.
When they make a selection, they will be presented with another screen/menu when they will do some work. When they are finished this work, they will press a key that will take them back to the root menu.
The key thing I'm after is for it to not be a scrolling view that just adds more information to the end. I'd like it to have distinct, encapsulated views with a navigation hierarchy. My problem is that I don't know how to produce such a view and present it to the user, and then dismiss it again once they're done. If someone could give me some kind of design pattern for this kind of application, I'll be able to take it from there.
FWIW, I'm using Ruby and would like the app to be cross-platform. If that's too much to ask, then Windows will suffice.
I'm a Linux guy and I want to suggest ncurses library for you. there's an ongoing effort to port this also to Windows.
AFAIK it's going pretty well, please check this question.
What is your biggest pet peeve related to the windbg debugger from microsoft?
(note: I actually really like windbg if I ignore the unpolished UI.)
Attempting to dock a window is almost always the wrong kind of dock the first time until :I move the mouse just right. Why can't it have the docking cues that VS2008 has?
The ridiculous behavior when you attempt to use click-drag to select text on a line that is wider than its physical window.
The pieces of the history window that I need to copy/paste into bug reports are frequently wider than the physical window. I've gotten so used to the triple-click workaround that I find myself attempting to misuse triple click in other (well behaved) applications.
Key presses are ignored while the focus is in a source window. It's not like you can edit the source code from inside windbg. At least there's the Alt-1 workaround.
How insanely slow .kdfiles copies new binaries across the 1394 connection. It can take up to one minute for a large dll.
Not being able to switch from output window to command window using a key press, I read that 'Alt+1' should work but it doesn't always so I always have to resort to using the mouse. Also sometimes it doesn't remember when I tell it not to ask me everytime if I want to save the workspace when I quit.
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\