I am programming using C++ /CLI with wxWidgets on Windows 11.
I'm Also Using .NET threads
When I create a wxMessageDialog in a secondary thread and run ->ShowModal() , it works.
But when I create a custom dialog in a secondary thread, running ->ShowModal() pops up a wxWidgets debug alert window :
I tried searching on the wxWidgets forum for the same issue but couldn't find one. I found similar issues but none of them addresses my problem.
I also tried to surround MyCustomDialog->ShowModal() with calls to wxMutexGuiEnter(); and wxMutexGuiLeave(); , but that also didn't work.
I also learned about wxThread while scrolling through the forum but if wxMessageDialog works without me having to create a wxThread, I shouldn't have to create a wxThread myself.
I know I shouldn't be calling GUI methods from a secondary thread, but somehow wxMessageDialog's ShowModal() doesnt have a problem with that.
I would like to know how wxMessageDialog works, and if I can implement the same thing with my custom dialog.
Thank you.
In a few words, no there's no way to use a custom dialog from a secondary thread with current implementation and in the foreseeable future.
Even though your current code works today using wxMessageDialog, there's no guarantee that it will continue to work tomorrow, or on different Windows version or on other OS.
Some more details:
wxMessageDialog and a custom dialog are significantly different internally, even though they represent similar UI features.
wxMessageDialog has native implementation, and you can find its wxMessageDialog::ShowModal() implementation in src/msw/msgdlg.cpp.
A custom dialog will be assembled an run by wxWidgets code, even though the dialog itself and other components are native widgets. You can find wxDialog::ShowModal() in src/msw/dialog.cpp.
If you really want to pursue some experimental development (because it would still not be suited for anything else), and being on Win 11, you could try wxRichMessageDialog. It provides more features than wxMessageDialog and on Vista and later versions it has native implementation, which might go along with your "hack".
But again, using UI from secondary threads will lead to a dead end sooner or later.
Related
I'm probably way out of the loop, but it seems weird to use a native look GUI library and then - if you're not using wxGTK - shoehorn in a text renderer from a different GUI library. What's the deal here?
I think I understand your point. Using GTK (and Pango Cairo) on Windows, by telling wxWidgets to use internally GTK seems duplicating window managers.
It's just a matter of taste. GTK in Windows does call Windows API to do windowing. But some users like the GTK-way for windows, menus, and other controls instead of the native Windows-way, and wxWidgets provides this feature (in addition, of course, of the native usage, keeping native look&feel).
Anyhow, GTK on Linux calls internaly X11 or Wayland for handling windows and menus. Do you also call this "duplicating"?
The question seems to stem from a mistaken assumption, so it's hard to answer it, let me rather explain how things really are instead:
Cairo-based wxGraphicsContext can be optionally used under MSW because this allows to produce exactly the same graphics output under all platforms, which can be important for some kinds of applications. However it is not used by default, you need to explicitly request it, and if you don't you'd be using GDI+ or Direct2D, both of which are perfectly native libraries.
My program may have several top-level windows open at a time, and I need to send a particular message to all of them (a notification of a change). I know how to do it using the Win32 API, but this is a cross-platform program using wxWidgets. I can't seem to find anything in the wxWidgets documentation about this, but that may simply be because I don't know what to look for.
I can solve this by having each of the top-level windows register itself with the wxApp object when it's created, but that's a manual process that I'm likely to forget on occasion, so I'd rather avoid it if possible. Does anyone know of an existing solution?
There is a global variable wxTopLevelWindows that is a list of the top level windows. See this wxWidgets Discussion Forum thread
I would like to create a trading bot for Magic Online. If it's a concern, doing that would not violate the terms of use, and several vendors for such a bot exist. I initially started out with the DLL injection/API hooking path, but that doesn't work as it doesn't seem to call any of the standard GDI functions. My code works fine on Notepad, but does nothing on MTGO_NET. Same result with third party hooking libraries.
I then "gave up", and decided to try to use OCR. However, this weird thing happens when I try to do a screenshot of the client window: I only get the game's splash screen, no matter what the client is actually displaying. The main window device context is always the splash screen. I am guessing the client uses a separate device context to actually render the game, and I have to somehow figure out what that DC is. Does anyone have experience encountering this issue? I would gladly take any advice regarding either hooking .NET applications or how to take a screenshot.
I am testing all this on Windows Vista Ultimate 64 bit. I haven't tested this on a 32 bit installation, but I hope that isn't an issue.
I suggest you look here: http://www.mtgnews.com/showthread.php?t=191879
Which provides a link to source code for a 'working' bot.
The result of a google search............
I'm trying to create a window switching application. Is there any way of getting a list of the windows of other applications, ordered by recently used?
Start with the Accessibility framework. Many of the hooks for screen readers are also useful here. Particularly look at the UIElementInspector sample and the NSAccessiblity protocol.
There's also Quartz Window services, which can easily give you a list of all the windows on screen. Unfortunately, it doesn't tie into concepts like window focus (just level), and I don't know of a way to get notifications back from it when levels change. You might do something like tap into the Quartz Event framework to capture Cmd-Tab and the like, but that's complex and fragile. There is unfortunately no good way to convert a CGWindowID into an AXUIElementRef (the post is for 10.5, but I don't know of anything that was added in 10.6 to improve this). But hopefully you can do everything you need through the Accessibility framework.
You would want to use
[NSWorkspace runningApplications]
to get you a list of all the applications running, and watch
[NSRunningApplication currentApplication]
to know when the user switches to a new application to keep up with which one is used more recently.
I wish to write a utility to auto-hide the menu bar, much like the dock. This would
replicate the a OS X 10.4-only application "Menufela", but for Snow Leopard.
[[NSApplication sharedApplication]
setPresentationOptions: NSApplicationPresentationAutoHideMenuBar
| NSApplicationPresentationAutoHideDock];
This code auto-hides the menu bar (and dock), but only in when the application is the frontmost window. How would I go about applying this behaviour system wide, regardless of what application is open?
The only thing I can think of is an InputManager, but I haven't written one before, thus I'm unsure if this is the correct way to go about it..
Also it seems InputManagers are limited as of Leopard/Snow Leopard - from this SO question:
it won't run them in a process owned by root or whell, nor in a process which has modified its uid. Most significantly, 10.5 won't load an Input Manager into a 64 bit process and has indicated that even 32 bit use is unsupported and will be removed in a future release.
I'm not concerned about the "will be removed in a future release" (it just has to work on Snow Leopard), and I don't think root-owned processes are an issue (all GUI applications should be running as the current), but presumably the code would have to be injected into many 64-bit applications (Finder/Safari/etc)
(I originally asked this on SuperUser, here, but as there was seemingly no existing utility to achieve this, it's more relevant to StackOverflow)
The kiosk API is probably your best bet for this, though I haven't used it in years and don't know if it's even supported anymore.
http://developer.apple.com/mac/library/technotes/tn2002/tn2062.html
I hacked together a small SIMBL plugin to hide the Menu Bar: http://github.com/Crazor/MenuBarHider
It uses the SetSystemUIMode() Carbon call, which is not limited to 32bit apps.
I haven't used it on Snow Leopard myself, but the only way of injecting systemwide that even has a chance as far as I know is mach_star, and even that will be a bit tricky. Apple isn't making this easy these days, which is why a lot of the old hacks are failing to be updated either in a timely manner or at all.
This recent Cocoa With Love article has information on how to hide the menubar:
http://cocoawithlove.com/2009/08/animating-window-to-fullscreen-on-mac.html
However, using the CarbonAPI (SetSystemUIMode()) requires the app to be 32-bit and does not work outside the scope of the application.
Edit: and reading a bit further, it seems that this API doesn't do anything that -[NSApplication setPresentationOptions] can't do.