I would like our team, to be able, to communicate to others easily, if they have suspended their work with a given reason.
So I would like to have the WIT's with an additional state named "suspended" and an given comment.
What we now would like to achieve, is that the newly added suspended state is set, when we press the suspend work button.
How to add an additional state is clearly documented on the msdn, but is there any possible way, to achieve the above mentioned behaviour, where we do not have to switch to all the associated WIT's and set the state manually?
Your requirement can't be achieved by default. You would need to customize your own add-in in VS.
Related
I have to enumerate all process running on my machine and notify if some changement will happen (for example: change of visibility of windows, open a new window, close a window).
To enumerate all processes I can use this function provided by MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682623(v=vs.85).aspxI thought that I need to save a list of running processes and check (how without polling?) if it changes. Can I do it without saving current running processes?
For the visibility changes here https://msdn.microsoft.com/it-it/library/windows/desktop/ms646274(v=vs.85).aspx I found that VM_ACTIVATE message is sent to both windows. How can I catch it? Can I do it in another way?
For whom is interested in this topic, I found that to check if a window is created or destroyed I've to use SetWinEventHook(), like in the example of its MSDN page. I simply check if event value is EVENT_OBJECT_CREATE or EVENT_OBJECT_DESTROY. For other events, check the event constants list.
I need my Visual Studio extension to react to debugging events. I've registered a IDebugEventCallback2 and I'm receiving events, but all I get for each event is an opaque IDebugEvent2 and a Guid, many of which are not only undocumented but don't appear anywhere on the web (or in my registry).
My specific requirement at the moment is to know when the process is Continued - ie. the user has hit Continue, Run to cursor, etc. What Guid should I be looking for?
Or is there some other event family that I should be subscribing to?
(More generally, is there some way I'm missing to find out about the events that are delivered to my IDebugEventCallback2::Event callback, when many of them don't appear in MSDN or anywhere else? Thanks!)
There is no easy way to do this. Actions such as Continue and Run to cursor are abstractions implemented by Visual Studio and do not correspond to any unique event(s) with respect to the debug engine. The debug engine event reporting interface IDebugEventCallback2 will enable you to get notified only on fine-grained events such as when creating a breakpoint or reaching a breakpoint.
While Visual Studio enables you to perform actions such as Continue and Run to cursor programmatically, it does not provide a direct way to get notified when they are taken.
You can use EnvDTE.DebuggerEvents.OnXxx events to get notified when something is about to happen. In particular, the OnEnterBreakMode event enables you to intercept a breakpoint hit and possibly take an action. You can also inspect all the details of the reached breakpoint(s) using the current EnvDTE.Debugger inside the event handler.
Now with some effort, you can use these constructs to implement events that correspond to all Visual Studio debugging actions including Continue and Run to cursor accurately. If you require additional events not provided by EnvDTE.DebuggerEvents (such as when a breakpoint is inserted), you have no choice but use IDebugEventCallback2.Event. In this case if you have specific events in mind, please mention them explicitly and I might be able to tell you the corresponding IDebugEventCallback2.Event GUIDs.
You probably got off on the wrong foot here, the IDebugXxx interfaces were really intended to create your own debugging engine. Still useful perhaps to see what is going on in the existing engine, you are suppose to use QueryInterface() to discover the specific interface that matches the event. Like IDebugEngineCreateEvent2, IDebugProcessCreateEvent2, IDebugProcessDestroyEvent2, etcetera. There are a bunch of them, they are listed in the VSSDK\VisualStudioIntegration\Common\Inc\msdbg.h header and include their IID.
Best thing to do is peek at this sample, it shows how to crack the event notification into the specific interfaces. The AD7Events.cs source file shows the wrappers. Do keep in mind that this sample was made to show how to create an engine, not how to use the one already built into VS.
But yes, you are not going to get a "continue debug" event out of this. A debugging engine does not need that event since it is already responsible for taking care of that by itself. It already knows when it calls IDebugProgram3::Continue().
Surely what you are looking for is IVsDebugger.AdviseDebuggerEvents(). That's the one that tells you what the built-in debugger is doing. You need to pass an object of a class that implements IVsDebuggerEvents, your OnModeChanged() method will be called with a DBGMODE notification. I don't see a lot of fantastic examples that demonstrate usage, this web page might be helpful.
Can anyone explain what using GCF as a "closed container" actually means?
I understand from this link that you enable this mode of operation using the HandleTopLevelRequests registry key.
I actually stumbled onto this setting as a way to prevent the Developer Tools window from automatically closing upon postbacks/redirects. That default behavior really makes the Network tab almost useless. :(
By setting the HandleTopLevelRequests registry key as described in the link above, the Developer Tools window remains open like I want.
I just don't know if this is a setting I should leave in place because I don't really understand what it's doing.
Or I suppose another way to ask it is, why wouldn't you want the HandleTopLevelRequests setting in place?
**Another registry key named UseChromeNetworking seems to often be used in conjunction with HandleTopLevelRequests. Bonus points for any details on it as well. :)
Any info at all would be appreciated-
Hopefully this question has a simple answer i'm overlooking! I have an IIS webserver with multiple sites on it. In Perfmon, they show up as w3wp#1, w3wp#2, etc... I'm writing a Logman script that will collect performance counter data using the counters/instances that I specify and I want to ONLY collect any w3wp worker processes.
I've tried a couple ways, but no luck:
\.NET CLR Memory(*w3wp*)\
\.NET CLR Memory(w3wp#*)\
\.NET CLR Memory(w3wp*)\
I've looked at the documentation here, and it seems like it claims to support wildcards, but not partial matches. I'm not sure what to make of that. Is there any way accomplish what I want? Hope I explained this well enough. Let me know if more details are needed.
Thanks!
There is a way to display the instance by appending Process Id to it. Since ProcessId do not change it helps determining the correct instance. This post describes the method - Perfmon: Identifying processes by PID instead of instance.
Relevant part from the link:
Making below registry change will display processes in the format of **ProcessName_PID** instead of **ProcessName#1**.
Click Start, click Run, type regedit, and then click OK.
Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance
On the Edit menu, click New, and then click DWORD Value.
Right-click New Value #1, click Rename, and then type ProcessNameFormat to name the new value.
Right-click ProcessNameFormat, and then click Modify.
In the Data value box, type one of the following values, and then click OK:
1: Disables PID data. This value is the default value.
2: Enables PID data.
Exit Registry Editor.
Warning: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Important: If you enable this feature, you may be unable to monitor process-specific information by using third-party utilities or custom-made programs, and this functionality may change at any time in the future without notice.
Hope it helps someone.
I came up with a custom batch script that find the application pool ID, PID, and associates it with the IIS worker process in question. From there, I can manually FIND and REPLACE a generic placeholder in my perfmon configuration file to start collecting for the specific site(s). I can supply some details if there is interest.
I'm writing a DLL that is automatically injected on load in a specific application. Because I'd like to run the program while working on it, and my users might want to load the program without it in specific cases (e.g. bug hunting), I sometimes want to prevent loading the DLL.
Currently I do this by checking GetKeyState for VK_LCONTROL, VK_LSHIFT , and VK_LMENU on load, and if all are down, I silently unload myself.
However, it can take quite a few seconds for the program to load and to see if the DLL was loaded or not, so I want to inform the users when we're unloading. I've considered a MessageBox, but that's too disruptive. I've tried MessageBeep, but that didn't seem to do anything on my setup. Currently I'm using a simple dual beep (Beep, Sleep, Beep) to indicate unloading, but that will probably become rather annoying to my co workers. I've also considered a system-tray icon, but that would introduce a lot of code and bug potential, while I'm aiming for a minimal notification as to not introduce any subtle bugs.
Would anyone else know a subtle way (preferably visual) to inform the user that their input has been succesfully received?
Given the limited scope of your goal, this might actually be an appropriate use of a taskbar notification balloon tip.
Edit: Added link the Joe posted in his concurring answer. Thanks, Joe! :)
If your app has a status bar at the bottom, you could place some message text there...
Have you considered a timed messagebox that closes itself?
http://www.codeguru.com/cpp/misc/misc/messageboxhandling/article.php/c203
You could open a window with a short message and close it automatically again after 0.5 seconds or so. It doesn't need user interaction so I don't think it's very disruptive.
Change the window title, then change it back afterwards. Then you can see the change even if the user has Alt-Tabbed over to some other program in the meanwhile, without stealing the focus from the user.
Concur with Greg D.
Look here: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/15cbdc8d-fde3-44ab-bbbc-e50cb2071674/
Two ideas:
Turn it around. Have a visual indication when the DLL is loaded, and have the absence of the indicator let you know that the DLL has been unloaded. Perhaps a suffix in the title bar. That way, you can tell at any time, not just during startup.
FlashWindowEx.