the help says: -
CreateWnd is called automatically when the control is first created or when the underlying screen object must be destroyed and recreated to reflect property changes. Override CreateWnd to pass additional initialization messages to the screen object when it is created.
I’m relay asking what are all the tasks to be completed in CreateWnd?
My CreateWnd is giving the error straight after inherited - has no parent window or path to form1 - so it it asking for the parent object in the return?
Its a procedure so it has nothing to return?
So is the proper thing is to remove inherited?
I have nothing in my component state
it calls procedure CreateParams(var Params: TCreateParams);
Params.WndParent is Nil that I think is the fault - but where should it be set in my code
this object’s parent is set to ‘owner’ ? should that not be picked up some where
or is CreateWnd been called some how prematurely?
Is their a RecreateWnd; call some where before a parent = is able to be called
is this likely to be in a windows message example: - CMCtl3DChanged?
So I’m saying what windows messages are excited with a TCustomControl.Create?
I found
procedure TWinControl.RecreateWnd;
begin
if WindowHandle <> 0 then Perform(CM_RECREATEWND, 0, 0);
end;
So how does RecreateWnd; get excited without a handle?
CreateWnd is usually used for components that implement wrappers for Windows UI controls, to set up window styles etc for the new instance as set in the component properties.
You mean executed? For instance from property setters, eg if a window (handle) has to be created with a different style.
so if the boarder or scroll bar is adjusted as in my object so you use RecreateWnd to excite createWnd from Windows into the object. RecreateWnd is in no other place in my object. createWnd is not directly called in my object - that’s a no no.
where else can createWnd get excited???
I should see the handle in CreateParams(var Params: TCreateParams); Params.handle but in tracing the handle is not there so the object does not display.
so createWnd is excited without RecreateWnd some how but I don’t know where?
Its getting excited without the handle some how from some unknown location and some where from the create process before I can get the parent = form1 a process to start or some how the handle is removed but how?
Am I thinking correctly?
can timer be behind the delivering a delay to CreateParams(var Params: TCreateParams); execution so the order of the create items in create be something?
i am going to check the use of handles in the object
but would like to know what events are done before CreateParams(var Params: TCreateParams); is executed
Does MS have anyrthhing to read on this subject you know of
However, I think it would be better if you can clearly and fully explain what it is that you are trying to do, as I’m struggling to put context to your posts.
Rather than destroying part of an object, I hid the object so the losing handle issue is not their and I redirected the focus to another object and it achieved the same presentation result on screen but is a little larger object.
In the last 3 months I have leaned a heap about objects internals
What I do not know is the messaging order and how its done.
I mean on a TCustomControl.create it must implement some of these
do they get placed in a list of events in windows messaging system or TApplication
and then proceed in a known order so if something is called twice it only run once?
Most of these messages are sent when the OS decides to (not necessarily in any specific order) and the object you implement handles the message as appropriate, depending on it’s internal state. The WM_ messages can be read about on Microsoft’s web
WM_ messages are windows
but CreateParams and CreateWnd is not windows are they in TComponent or something? do they get excited something like after the constructor create?
And their is no real order
I notice some objects can call invalidate in the same object more than once or paint more than once when the user example presses a mouse button
dose that make invalidate or repaint be excited many times?
I did this once
TTimer I SetTimer twice with the same ID and it came through the timer event twice
on the same ID. So I made a procedure that identified if it was already set before and the timer had not completed its time, with the value cleared at the timer event so if called many times it can only run once at a time - is all messages like this?
Hi @NickR - I deleted your post since it contains a link to a pirate site - and the document linked to has no info on who the original author is or what the copyright situation is. These forums are public and the last thing we want is the hassle of a copyright infringement.
Edit - that pdf was from
Borland Delphi 6 Developer’s Guide by Xavier Pacheco & Steve Teixeira
My sincere apologies. I knew of a document covering Windows Messaging and when I googled, it came up with that one (which I thought was the one I was looking for).
I did not on purpose mean to link to copyright material.