I would say a Windows App built on REALbasic MacOS IDE, and Windows
App Built on Windows IDE should be
exactly the same, anything else would be a serious bug in REALbasic.
Have you tried comparing the 2 EXE files with some binary comparison
tool ?
If they are different then REAL at least should be very interested in
it.
You may want to shut down REALbasic, clear the plugin cache on both
machines and re-do the test with the cache clean.
Björn
On 14.5.2006, at 21:40, Alfred Van Hoek wrote:
1) It is not a difference in the class' struct size.
2) When the windows application is build with the MacOSX RB-IDE
everything is fine. The Appl.exe runs fine and also quits fine.
However, when the windows application is build (or run in the
debugger) with the Windows RB-IDE another behavior of the Appl.exe
is experienced. It runs fine but when the application quits, it is
going to hang after the destructor of the REALcontrol was called.
The REALcontrol *gist* is the loading of a dynamic library and the
submission of the REALcontrol-HWND to this library. This library
will subclass the REALcontrol-HWND and as a result most of the
REALcontrol-behavior callbacks will not fire. If we do not do
anything further a build Appl.exe will run fine and quits fine too.
To provide mousedowns, mousedrags and mouseups to the user of the
plugin we subclassed the REALcontrol-HWND too, but after the
submission to the library. And this leads to the description above
in (2).
Is it possible we made a mistake?
Here is the gist of subclassing:
// This call when appropriately chosen in the chain of initializing
events subclasses the window after
// the library has subclassed the window
static void SubClassLibraryWindow(REALcontrolInstance instance,
HWND hWnd)
{
ControlData(DylControl, instance, DylData, data);
dlog("SubClassLibraryWindow");
if(hWnd) { // Subclass
dlog("Valid hwnd");
data->oldWindowProc = (WNDPROC)PGetWindowLong(hWnd,
GWL_WNDPROC);
data->oldUserData = (void*)PGetWindowLong(hWnd, GWL_USERDATA);
// data->oldUserData will not be nil if the dylLib had
subclassed it hwnd already
PSetWindowLong(hWnd, GWL_WNDPROC, (LONG)Parent_WndProc);
PSetWindowLong(hWnd, GWL_USERDATA, (LONG)data);
}
}
// the following unsubclasses the hwnd
static void UnSubClassLibraryWindow(REALcontrolInstance instance,
HWND hWnd)
{
ControlData(DylControl, instance, DylData, data);
dlog("UnSubClassLibraryWindow");
if(hWnd) { // Unubclass
dlog("Valid hwnd");
PSetWindowLong(hWnd, GWL_WNDPROC, (LONG)data->oldWindowProc);
PSetWindowLong(hWnd, GWL_USERDATA, (LONG)data->oldUserData);
}
}
For sake of completeness:
LRESULT CALLBACK Parent_WndProc (HWND hWnd, UINT theMessage, UINT
wParam, LONG lParam)
{
DylData *data =
(DylData*) PGetWindowLong(hWnd, GWL_USERDATA);
.....
switch (theMessage) {
case WM_LBUTTONDOWN:
if (data->_MouseDown)
data->_MouseDown(data->self, pt.x,
pt.y);
break;
case WM_LBUTTONUP:
if (data->_MouseUp)
data->_MouseUp(data->self, pt.x, pt.y);
break;
case WM_SETFOCUS:
MSG(wm_setfocus)
if (data->_GotFocus)
data->_GotFocus(data->self);
break;
case WM_KILLFOCUS:
MSG(wm_lostfocus)
if (data->_LostFocus)
data->_LostFocus(data->self);
break;
case WM_MOUSEMOVE:
if (GetAsyncKeyState(VK_LBUTTON) << 16)
{
if (data->_MouseDrag)
data->_MouseDrag(data->self,
pt.x, pt.y);
}
break;
case WM_KEYDOWN: {
uint32 keyCode = (uint32) wParam;
break;
}
case WM_CHAR: {
Boolean value = false;
uint32 c = (uint32)wParam;
if (data->_KeyDown)
value = data->_KeyDown(data->self, c,
c, 0);
break;
}
case WM_KEYUP:
dlog("WM_KEYUP");
break;
}
// Pass the message on to the old window proc, reinstating
// the previous user data before you call it.
LONG curUserData = PGetWindowLong(hWnd, GWL_USERDATA);
LONG curWindowProc = PGetWindowLong(hWnd, GWL_WNDPROC);
PSetWindowLong(hWnd, GWL_USERDATA, (LONG)data->oldUserData);
PSetWindowLong(hWnd, GWL_WNDPROC, (LONG)data->oldWindowProc);
LRESULT result = PCallWindowProc ((WNDPROC)data-
>oldWindowProc, hWnd, theMessage, wParam, lParam);
PSetWindowLong(hWnd, GWL_USERDATA, (LONG)curUserData);
PSetWindowLong(hWnd, GWL_WNDPROC, (LONG)curWindowProc);
return result;
}
Why would the Appl.exe build on the Mac not crash on quit, but will
crash when the Appl.exe is build on Windows????????
Stunned,
Alfred
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
