Defining a custom *constructor* (not initializer!)

[Steven Schveighoffer]

On Fri, 11 May 2012 10:31:26 -0400, Mehrdad <wfunction at hotmail.com> wrote:

> On Friday, 11 May 2012 at 14:20:47 UTC, Mehrdad wrote:
>> On Friday, 11 May 2012 at 14:17:04 UTC, Steven Schveighoffer wrote:
>>> Yeah, but given that the subclass is calling the base constructor, and  
>>> the base constructor does not return until WM_CREATE is received,  
>>> can't the subclass constructor pretend it received the message?
>>>
>>> -Steve
>>
>> "pretend"?
>>
>> The subclass has NO access to the window handle whatsoever before the  
>> message comes, so no, it can't "pretend" to have received the handle  
>> because that wouldn't be of any use.
>
>
> Or did you mean *after* the base class constructor is called?
>
> If you meant that: no, that's pretty useless because the whole
> point of receiving a message is to respond to it appropriately!
>
> If you miss the actual notification you can't time-travel back
> and say, "just kidding, I actually wanted to do X-Y-Z when the
> message came, so can we redo this whole window creation thing?" :P
>
> That's exactly what I was saying when I said that you can't
> afford to miss a message and hope that you can just change stuff
> later...

Yes I did mean that.

I'm thinking about it, one thing you did not mention, but almost certainly  
is the case (it usually is with GUI toolkits) is that the WndProc is  
called in a different thread or context than the constructor.  This means,  
there may be functions that you can call in WndProc that you cannot call  
in the ctor.  So even though CreateWindow returning means WM_CREATE must  
have been received, the context you need to handle WM_CREATE is gone.  Is  
that true?

I'll wait for an answer before thinking more about this.  It feels  
imminently solvable...

-Steve