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.
Related
Back when I was a kid, we used an old MS-dos system to navigate programs, menus and games. All I can seem to remember is that we started the program by typing "menu" (or it was in the autoexec). I can't recall further about the name.
This was back in the beginning of the 90'es, but the system could have been developed earlier, but I recall using the cd and cd.. to navigate earlier than that.
I also remember that you could edit the menus by adding/removing items by pressing SHIFT-F[x] (I could be wrong about the shift, but it was an modifier and an F-key), and an item was added by modifying a number of batch-commands. This could either be a new page of menues or a command to a program.
My memory tells me that it looks something like this;
Can anyone tell me more about what this program was called and maybe even if it is available as download somewhere?
(Edit: Updated title)
I remember DrMenu and Fixed Disk Organizer (from IBM) but I don't remember their appearance.
I remember a similar program on my fathers PC (or rather AT) back in the late 80's/early 90's. I think it was made by Scandinavian PC Systems, or SPCS for short. I doubt Visma (that now own the brand SPCS) have it for download somewhere, and my answer is not a complete answer but I can not add a comment so I hope you excuse me for trying to help out in this way.
When some programs are opened they automatically cascade (when not opened in full screen), and I want to keep all documents directly on top of each other. I found this which claims that it is impossible.
I know that it can be done by having AutoHotkey watch if newly opened windows are not touching a border and moving it to the closest border, or to watch the position of the window when it is activated. Does anyone know of a good way to solve this using e.g. AutoHotkey?
The only working solution I have found so far is using DisplayFusion, which solves this using the setting
"window location". Here’s a short guide. I also found that there is a way to script it using the same program.
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 just started a new task at a "lower level" in the platform stack, and I'm getting started with windbg. I'm so far quite happy with the pure power of the debugger. However, I wish it would just save my session default, like the VS debugger does. What I want is that whenever I ".restart", or re-open windbg, it works just like I left it: same bp's, same sxe state, same files open in the same places, etc.
I know about "save workspace" which seems to do what I want, but it's manual, and I have to do it every time I make a change to the workspace state.
Is there a way to just have windbg do this automatically?
It should prompt the first time you close the session and ask you if you want to save your workspace, there is a checkbox like the image here.
If you click yes this time and the box 'Don't ask again in this WinDbg session' then it will automatically save your workspace, similarly you can also clear the workspaces if it's erroneously saved some breakpoints or paths that you are no longer interested.
Also you can set this in the options like so:
Microsoft NTDebugging Blog. Uncovering How Workspaces Work in WinDbg.
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.