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, …