I want to create an wxWidgets app that is loaded from a shared library. It should be added as a plugin to an already existing C application.
In the samples directory (/samples/dll) of wxWidgets i found the file "my_dll.cpp". It's exactly what i need. It is exclusively for windows though. I need to make a .so linux version of it.
So i rewrote everything winapi thread related with pthreads. I have never really done multithreading so there are probably lots of mistakes in the code but i am not able to find them.
Maybe someone can help.
the most relevant functions are:
void run_wx_gui_from_dll(const char *title)
and
void* MyAppLauncher(void* event)
here is a link to the samples file from wxWidgets that uses winapi threads http://pastebin.com/KhK4uiKZ
here is a link to the code that uses pthreads http://pastebin.com/QmsPqYs5
My pthread version only works correctly when i put a sleep at the end of run_wx_gui_from_dll.
Without the sleep CMD_SHOW_WINDOW won't open a new frame. Just nothing happens. I put puts("received show window command"); in void MyDllApp::OnShowWindow. The string is printed to stdout so i know that wxQueueEvent works.
But wxWidgets seems to block at wxFrame *f = new MyDllFrame
...
...
// Send a message to wx thread to show a new frame:
wxThreadEvent *event =
new wxThreadEvent(wxEVT_THREAD, CMD_SHOW_WINDOW);
event->SetString(title);
wxQueueEvent(wxApp::GetInstance(), event);
sleep(3);
}
The windows version does not need a sleep.
run_wx_gui_from_dll starts a new thread from which the wxWidgets event loop is called. It then needs to wait until wxWidgets is properly initialized until it can queue commands. That is why i used the pthread condition. The windows version does a similar thing.
I also don't know what wxCriticalSectionLocker does. I left it in there just in case. Maybe that's part of the problem.
One error I see in your code is that you must lock the mutex before launching the thread, otherwise it may signal its initialization before you started waiting for it. I'm not sure this explains your problem (in fact, it probably doesn't), but it would still be nice to fix it. And if the problem persists, I'm afraid you really need to debug it and see what's going on, i.e. which thread is doing what.
It's also definitively a pity that we can't just use wxThread here, it's pretty annoying to have to write platform-specific to initialize a platform-independent library. We really ought to add some wxInitializeInNewThread() or something like this... If, by chance, you'd be interested in contributing it, please don't hesitate to post to wx-dev mailing list.
Related
I have an application that opens another process and modifies its memory. What I'd like to have as a part of the GUI is a label that updates (perhaps every second or so) to let the user know if they're attached to the other process.
When the application is found running, I'm creating a handle to it, obtaining the base address of it, and then the rest of the work is done through button clicks and hotkeys. Anyway, for each time the application is found running, I want it to do all the things I have it do to obtain the handle, etc., etc.
This way, the other application can be closed and reopened without my app also needing to be closed/reopened accordingly.
Thus far, my research has led me to CreateThread() and std::async (as well as std::launch::async and std::launch::deferred). The issue I'm having is I can't seem to find examples of infinitely-running asynchronous code (in its own thread, perhaps). I'm having a difficult time wrapping my head around how to make this happen, as everything I've tried still keeps execution from continuing as if I'd just written a while loop in main() or something.
Anything exemplifying the type of functionality I'm looking to achieve would be immensely appreciated! Thanks for your time and help, everyone.
I have an MFC based DLL.
I have a phenomena that the main application which loads my DLL crashes upon exiting.
The application developer suspects it relates to my DLL and wants me to scan my code for any leftover timers, events, threads etc. when the DLL unloads.
What are the best ways I can approch this task?
I work on VS2008.
Best regards,Tal
The question of itself tells me that there is a high probability your college is wrong. Most developer know about that kind of resources.
But anyway, search for:
SetTimer -> There should be a KillTimer
AfxBeginThread -> you should wait on thread end before you let anyone unint your dll
CreateThread -> same as AfxBeginThread
Look where you set CALLBACKs in Win32 or Afx functions. You have to make sure that you won't be "called back" after DLL is closed.
Non modal dialogs like toolboxes are sometimes also a problem. The should be ended cleanly.
If you have control of the interface the DLL uses, introduce a dedicated uninit function/method. Make sure you throw an exception if anyone accesses any resources after the call of that uninit. If there is already something like a uninit or close command, use that.
Write your own DllTestProgramm. Where you test your DLL with the same circumstances as the developer does.
After checkmark those points go back to the developer, tell him "it works in my program" he will love that.
Try installing the free Visual Studio 2013 Community Edition or a VS 2013 Trial Version. It has got a built in code analyzer capable of pointing out problems with your code.
This is a follow on from a question I asked about embedding Qt code in a legacy C application.
I am able to build Qt code into my C application and was surprised to find that I can even run gui code from within the static library I'm using to do this.
(My C application is also GUI driven, by the way).
This opens up some exciting possibilities, and I'm trying to get the two GUIs to work side by side.
The problem I have now is that in order to launch Qt GUI code I need to call QApplication::exec(), which is effectively blocking the rest of my application as it doesn't return until I kill the qt gui.
Is there any way I can start the qt gui code up and still return to my host application?
I appreciate I could start my Qt code up as a different process and implement some inter process communication, but the whole point is to try and get this embedded as a library.
There's also no way I can host the legacy application in Qt, before anyone suggests that!
Thanks for your help!
Don't call QApplication::exec(). Instead have the application call QApplication::processEvents() in it's event loop.
The answer to your problem is threading.
Since you are doing C, pthreads is probably available to you.
void * qt_thread(void * parm) {
// code here
QApplication::exec();
}
//some where in your main()
pthread_t qt;
pthread_create(&qt, NULL, qt_thread, NULL); //returns immediately
// rest of code
This is a VERY rough example, you should study and learn threading properly.
Good reference:
https://computing.llnl.gov/tutorials/pthreads/
Well, you can start a second thread (e.g., using the pthread library) and start QApplication::exec() from the second thread. However, you must be very careful when communicating with your QT code in order not to have race conditions in your library.
I'm writing a computer vision app (C++ and OpenCV). I am creating a GUI for it with wxWidgets - this is very simple; a button-press event calls the tracker app to begin.
My call to terminate the app (i.e. on clicking to close button) is as follows:
// Exiting the App
void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event))
{
// true is to force the frame to close
Close(true);
}
This usually works with more trivial GUI apps. However, on this occasion, the frame disappears yet, in the task manager, the process seems to continue running and holding memory. It's very annoying because if I run or debug the application and later make some changes and try to run again, without manually terminating the process beforehand, the compiler throws a link error because the .exe is
not found or not built by the last incremental link.
Tried inserting a brute force exit(1); in the onQuit method but it causes the app to crash.
I'm not sure what it is.. when running without the GUI, the app runs and terminates fine (albeit it is called slightly differently - from the main() function instead of from a button-press event handler which calls an abstract base class).
Is it possible that it is because a class is being declared with global scope? As in, in one file I have an instance of a class declared outside of any class method? Perhaps wxWidgets can't handle this?
To clarify:
The frame I'm closing is a top level frame. I had no problems with the exact same GUI code when it does not call the computer vision methods.
I haven't specifically coded any multi-threading but to begin with, I was getting an error that said "Error: Cannot initialize OLE". To fix this, I had to set wxUSE_DRAG_AND_DROP, wxUSE_CLIPBOARD, wxUSE_OLE and wxUSE_OLE_AUTOMATION to 0 (instead of 1) and then (re)compile wxWidgets.
Just wondering, is there some kind of threading going on with HighGUI that is inconsistent with WxWidgets? Has anybody else encountered similar problems?
::wxExit
void wxExit()
Exits application after calling wxApp::OnExit. Should only be used in an emergency: normally the top-level frame should be deleted (after deleting all other frames) to terminate the application. See wxCloseEvent and wxApp.
Include files
<wx/app.h>
You can also simply call the crt function exit() which will instantly shut down everything.
However, if you want to more polite than these rather brutal methods ( which you may want to do in particular if you have placed some special shut down code in wxApp::OnExit
) then you want to find the top level window and close that. To do this from anywhere in your code
wxGetApp().GetTopWindow()->Close()
Thanks for all the help, I have solved the problem. Seems fairly obvious now but couldn't figure it out at the time!
Originally, my computer vision app was called from a main function. However, with the new GUI code there is no need for a main so I replaced the original main with a shell class.
Though I had been careful to free allocated memory within the methods of my computer vision classes I had not been so careful with the original main function because once that function ended, all memory previously in use would be cleared up by the program's regular exiting.
The difference with the new GUI code is that when the shell class is finished - the program is still running. The clue was in the fact that even when the computer vision app had ended, the blue light on my webcam was still shining.
* Be sure to call cvReleaseCapture( &capture ); to free up that thread and release the hardware *
Your call to Close only closes the frame, but doesn't stop the application, because it is not the last top level window. The wxWidget contains a topic Window Deletion Overview. It states that
A wxWidgets application automatically exits when the last top level window (wxFrame or wxDialog), is destroyed. Put any application-wide cleanup code in wxApp::OnExit (this is a virtual function, not an event handler).
Is your frame the top-level frame? If not, you may have to call Close or Destroy on a top-level frame.
This is something that's been bothering me a while and there just has to be a solution to this. Every time I call ShellExecute to open an external file (be it a document, executable or a URL) this causes a very long lockup in my program before ShellExecute spawns the new process and returns. Does anyone know how to solve or work around this?
EDIT: And as the tags might indicate, this is on Win32 using C++.
I don't know what is causing it, but Mark Russinovich (of sysinternal's fame) has a really great blog where he explains how to debug these kinds of things. A good one to look at for you would be The Case of the Delayed Windows Vista File Open Dialogs, where he debugged a similar issue using only process explorer (it turned out to be a problem accessing the domain). You can of course do similar things using a regular windows debugger.
You problem is probably not the same as his, but using these techniques may help you get closer to the source of the problem. I suggest invoking the CreateProcess call and then capturing a few stack traces and seeing where it appears to be hung.
The Case of the Process Startup Delays might be even more relevant for you.
Are you multithreaded?
I've seen issues with opening files with ShellExecute. Not executables, but files associated an application - usually MS Office. Applications that used DDE to open their files did some of broadcast of a message to all threads in all (well, I don't know if it was all...) programs. Since I wasn't pumping messages in worker threads in my application I'd hang the shell (and the opening of the file) for some time. It eventually timed out waiting for me to process the message and the application would launch and open the file.
I recall using PeekMessage in a loop to just remove messages in the queue for that worker thread. I always assumed there was a way to avoid this in another way, maybe create the thread differently as to never be the target of messages?
Update
It must have not just been any thread that was doing this but one servicing a window. Raymond (link 1) knows all (link 2). I bet either CoInitialize (single threaded apartment) or something in MFC created a hidden window for the thread.