🚀 go-pugleaf

Keith wrote:
> Recall that you can #pragma the compiler options at will, or break portions of code into other module that
> have a single particular compiler control set.
> 
> What I do find interesting about this is that the code generated from your app didn't change, but the
> USER32.SendMessageA action did change.  This indicates to me that a different version of the
> USER32.SendMessageA function was provided during the link phase, or that somewhere in the include files is
> a definition for SendMessageA that can have varying compiled output depending on compiler options.
> 
> keith

Not only that, but the ctor for the combobox also called SendMessage:

WinComboBox::WinComboBox(WinControl * parent, int left, int top, int width, int height) :
             WinControlWin(parent, left, top, width, height),
             callBackFuncC(NULL) {

    idC.changeCallback(WinComboBox::comboBoxCallback, this);
    wCommandProcC = wCommandProc;
    DWORD style = WS_CHILD | WS_TABSTOP | ES_LEFT | CBS_DROPDOWNLIST | WS_VSCROLL	;
    hwndC = CreateWindow("COMBOBOX", " ", style, leftC, topC, widthC, heightC,
                parentC->hwnd(), (HMENU)idC.id(), gApp->hinst(), NULL);
    if (!hwndC) throw AppException("Unable to create window");
    SendMessage(hwndC, WM_SETFONT, (WPARAM)GetStockObject(DEFAULT_GUI_FONT),
                MAKELPARAM(false, 0));  //HERE!!!!
    setupWindowProc();
    ShowWindow(hwndC, SW_SHOW);
}

in the same unit and it didn't blow up there!  This makes me think that as the only thing in 
the add() routine is the SendMessage the compiler is somehow playing games, and if I was to 
place some dummy code after the SendMessage in the add() routine the problem might also be 
solved, but I haven't checked this assumption.

David

ps - I'm using BCB4.  What is your compiler?