Alexandre,
I've noticed a few things about WINE that might help you improve it. WINE can confuse SendMessage() with PostMessage(). LTspice uses SendMessage to handshake between threads sometimes. Wine usually obeys the difference, but treated some SendMessage calls like a PostMessage. My workaround was to poll volatile global variables.
I'd be interested to hear more details; SendMessage is definitely supposed to behave properly.
Here's the situation: The app has two threads. One is the whole MDI/user interface/CAD and text editor. The worker thread does a simulation of the circuit you draw in the CAD editor. The messages are all registered messages for a historical reason in a footnote(1).
The first message back from the worker thread says it's got some partial data to plot and sends a message to the view window that launched the thread. The view knows the name of the file containing the data and launches a doc/view to read it. That doc/view throws up a dialog asking which data to plot. The schematic doc/view and plotting doc/view handshake here by calling each other's functions and setting each other's data members. After the data is read, the original view to get the message from the working thread returns the number of data points that were found in the file. All this time the worker thread, having done a SendMessage() and not a PostMessage(), is frozen waiting for the return value of the number of points so it can decide where to try again or continue. The scheme that I'm using has been extensively debugged and used under 95,98,Me,NT,2K, and XP. But under wine, the worker thread doesn't freeze when it calls SendMessage() but keeps executing. It's imperative that it does because on subsequent calls from the worker to the UI thread, it sends little compressed packets of data. The UI must process these before the worker thread continues.
//Here's the code that worked under Windows:
int nPnts = SendMessage(TheChartWindow, WM_MARCH_INIT, 0, 0); if(nPnts != run->pointCount) // try again if it failed SendMessage(TheChartWindow, WM_MARCH_INIT, 0, 0);
// And here's the code hacked to work under Wine: volatile BOOL LinuxProcessed = FALSE; volatile int NumberPoints = 0;
unsigned MarchInit() { NumberPoints = 0; LinuxProcessed = FALSE; SendMessage(TheChartWindow, WM_MARCH_INIT, 0, 0); // the function that receives this will // assign the return value to NumberPoints // and assign a value to LinuxProcessed while(!LinuxProcessed) // Will Wine every simply ever lose the message? Do I need to time-out? Sleep(100); return(NumberPoints); }
int nPnts = MarchInit(); if(nPnts != run->pointCount) MarchInit();
I did find one other problem in Wine that may or may not be related to messaging, that being with the FindReplace common dialog. When you press "Find Next" which is IDOK, under Wine nothings happened in my app. My app uses one FindReplace dialog for all document types and relates the command to the active document. The workaround was to add an OnOK() handler:
// Wine is a global BOOL the TRUE if running under Wine void CFindDlg::OnOK() // for WINE { // for WINE if(Wine) // for WINE
{ // for WINE WineFindReplaceHack = TRUE; // for WINE LPARAM lParam = (unsigned ) this + offsetof(CFindReplaceDialog, m_fr); // for WINE ::SendMessage(theApp.m_pMainWnd->m_hWnd, WM_FINDREPLACE, 0, lParam); // for WINE WineFindReplaceHack = FALSE; // for WINE } // for WINE else // for WINE Default(); // for WINE } // for WINE
LRESULT CMainFrame::OnFindString(WPARAM wParam, LPARAM lParam) { CFindDlg *dlg = (CFindDlg *) CFindReplaceDialog::GetNotifier(lParam); . . . if(WineFindReplaceHack || dlg->FindNext()) { // search active document for dlg->m_findWindowText and highlight. } . . . return(0); }
Let me know if you have any other questions. I'd like to be as helpful as I can in this and immensely appreciate the help that, e.g., Uwe has been. I officially feel guilty that I'm not subscribed to the e-mail list, but I get too many e-mails and phone calls as it is.
--Mike
(1) Normally the graphical schematic drives the worker thread. but a text netlist can also be used. I used to use a CEditView for this netlist and under Win95, the original message scheme didn't work until I used registered messages. I no longer use a CEditView but an more general purpose syntax colonizing editor with unlimited undo/redo, so i don't know if the messages still have to be registered.