How to open a Win32 dialogbox from inside a VST plug-in? Thanks for any help.
You should be able to use the standard MessageBox() call, as described in this SO question. Not sure if this will work in a plugin without a GUI editor, though.
Related
I am using WinAppDriver to automate my LabVIEW app UI testing. Inspect.exe can detect top level of active window but couldn't locate element inside the window.
So I couldn't get the text inside the window. Does anyone know how I could get the text?
Thanks!
Mary
As it was said, standard UI automation tools do not work with programs written in LabVIEW. However, there are alternative solutions such as LabVIEW UI Automation Tool. You should check this out, it may be helpful for you.
Given a program process (say Visual Studio 2012), how can I access it's menu items programmatically?
I'm not at all sure what APIs I would use or how to even Google this.
Thanks in advance.
Start with GetMenu(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms647640(v=vs.85).aspx and over on the left are all the other menu functions. (Assuming you're talking Win32 API.)
Since it appears you have the process ID, you can find the main window's HWND from here: Win32 - Get Main Wnd Handle of application
unfortunately, more and more programs don't use the traditional "menu" subsystem. The answer given by Graham will work for some simple application, as calc.exe and notepad.exe, but not for VS2012.
I suggest using UIautomation.
The Windows SDks come with an "accessibility" tool, Inspect, that will show you if you can expect good support of UIAutomation by applications.
Microsoft now recommends using Accessibility Insigths instead:
https://learn.microsoft.com/en-us/windows/win32/winauto/inspect-objects?redirectedfrom=MSDN
I am trying to write a very limited taskbar replacement without the start menu and the standard desktop.
But now i wonder how explorer.exe works internally.
1.) How does the taskbar catch minimizing windows?
2.) How do the taskbar get to know when a window opens or closes or somthing? (Is there an api?)
3.) How does explorer.exe enable visual styles? (If it doesn't run all styles are disabled and it looks like win9x)
Review the SetWindowsHookEx() documentation in the MSDN Library. The important hook type here is WH_SHELL.
SetWindowsHookEx with a WH_CBT or WH_SHELL hook (I'm not sure if WH_SHELL works 100% on all systems when explorer is not running)
As far as #3 goes, I don't think I have seen that problem.
Explorer uses a lot of undocumented functions, you should take a look at some of the open source replacement shells or google RegisterShellHook, ShellDDEInit and ARW_HIDE
Check RegisterShellHookWindow, I believe Microsoft added it to avoid having to maitain a 32-bit and a 64-bit hook on newer x64 OS versions.
Is it possible to develop win32 UI application for Pocket PC with multiple dialogs
we need to display each dialog based on user input and hide previous dialog when current dialog is displayed on window.
Thanks in advance
Sure, that sounds a lot like standard application behavior, which is supported. The only thing not supported is MDI. Programmatically it's going to work just like on the desktop, so examples using calls to CreateWindow or CreateDialog will be applicable.
Using WinXP. What I need to do (pref in VB or c#) is to detect when another (closed source) program displays a notification balloon in the tray - and grab the details. Any help would be appreciated. Thanks
In similar situations, I have used the Microsoft tool Spy++ to grab the window information and then uses pinvoke calls to FindWindow to detect when the window is present.
I've not tried with a notification balloon, but I imagine that a pinvoke call to GetText would retrieve the contents.
I think you'll need to use pinvoke to do this from a .net language.
On the system I'm using now (Vista Business SP2), balloon windows always seem to have window class #32769 (reserved for desktop windows) and the windows style bit TTS_BALLOON set.
The following might work: Determine the parent window for all notification balloons by creating a temporary one, getting its hWnd, and calling GetParent() before deleting it. You could then periodically poll the children of this parent hwnd (using EnumWindows() or FindWindowEx()) looking for windows with the required class and style.
This seems highly non-portable to me, and likely to require a lot of testing on a variety of platforms.
pinvoke.net and spy++ might be useful.
Good luck!
You will definitely need to use Win API calls to achieve this. If this is the only thing you're trying to do, you'd be better off using straight C or C++ so you don't have to do a bunch of platform invoke for C# or VB.
Since andyjohnson identified that the window class for all notification balloons is #32769, and that they have the TTS_BALLOON style set, you could use a CBT hook (if you're not familiar with Win32 hooks, you might want to read up on them), to get a callback whenever a window is created, and check for windows of that class and with that style.
I'm not sure, though, if a new balloon window is created for second and subsequent popups or if the same one is just hidden and reshown. If this is the case, you might need a CallWndProc hook, to get WM_SHOWWINDOW messages.
Edit:
I should mention that the hooks that I've mentioned cannot be implemented in .NET. Except for the low-level keyboard and mouse hooks, global system hooks must be implemented in a native (unmanaged) DLL. Windows will load this DLL into other processes, and if a managed DLL gets loaded into a process that doesn't have the .NET CLR loaded, it will crash that process. (Even if the CLR is loaded, it might be at a different address, also causing a crash.)
So you must build your hooks in a native (unmanaged) DLL. It's possible to interface from here to a managed application, such as Michael Kennedy has done on Code Project, but to do it properly, and handle the hook types I've mentioned above, you'd need to use interprocess communication, a step that Michael Kennedy left out. All in all, for the purpose you've described, it would probably be easier to just build the whole thing in native code.