REALGetControlBounds and REALGetControlHWND issues (Windows of course)

In essence I am upset. Initially I thought things on the windows platform are really improving when it comes to developing a REALcontrol, given I can call now REALGetControlBounds and REALGetControlHWND in the Constructor callback (which was not possible earlier). And so I can call:

[code] Rect bounds;
REALGetControlBounds(instance, &bounds);
CRect rRect( 0, 0, bounds.right - bounds.left, bounds.bottom - bounds.top );
if ((bounds.right == bounds.left) || (bounds.bottom == bounds.top)) {
dprintf(“rectangle is not defined”);
}
if (NULL == REALGetControlHWND(instance)) {
dprintf(“The HWND handle is not defined”);
}
XRectControl xrect = instance;
if (0 == xrect.handle() ) {
dprintf(“The xrect.handle() is not defined”);
}
CScintillaDelegate delegate = new CScintillaDelegate();
delegate->initWithControl(instance);
CScintillaView
editor = new CScintillaView();

    if( editor->Create(NULL, NULL, WS_BORDER|WS_CHILD|WS_VISIBLE, rRect, CWnd::FromHandle(REALGetControlHWND(instance)), 0, NULL) ) {
        dprintf("created the view");
    } else
        dprintf("view was not created");

[/code]

in the Constructor callback, as it should.

And yeah in design time (IDE time) the rectangle is defined, and so is the REALGetControlHWND (dynamic access to the control.handle fails) and the zillion property getters and setters nicely affect the appearance of the control in the IDE, alleviating a lot of headaches. And so I was really happy, but, guess what…

The REALGetControlBounds in runtime and called in the Constructor callback does -not- get you a rectangle (but can be worked around of course), but the absence of a valid REALGetControlHWND cannot. And dynamic access is not doing it either.

I know, call it in the Open callback, we have been there and done that, but you know, you don’t need to do these kind of tricks when developing for the MacOSX platform. And with 64-bit around the corner, …

In IDE design time I usually draw simulated picture of the control just enough so the programmer can visualise his application when designing it. The way its engineered then its not good to try to embed something at IDE design time.

Björn, that is how it was, but note that the Xojo controls do embed cocoa controls, windows controls in design time. The Lexing plugin, is doing the same. The offscreen callback is used for drawing in design time. And you can invoke certain properties that call into a cocoa or windows control, which allows a user to examine the appearance of the control, without going into runtime. It is just now that porting the plugin to Visual Studio leads to a couple of issues, see <https://xojo.com/issue/40619>, that led me to reinvestigate whether or not the approach in windows with the current beta could be aka the approach in macosx. The plugin compiled by CodeWarrior is behaving correctly with the tricks you have to do for windows.