What is the difference between a window and a control?

[vfclists]

How do systems like X11 and Microsoft Windows distinguish between windows and controls?

It seems to me that windows are what controls are placed in.

I've come across a problem where after embedding a Emacs in a TPanel I am unable to get the Emacs to resize after resizing the TPanel, point being that X11 needs a different handle to the Emacs window itself.

There must be a way of getting Emacs to retrieve the handle of its frame (windows to other GUI users) but in the meantime I've got settle for a way by which TPanel can obtain the handle of an object embedded in it.

[Thaddy]

There must be a way of getting Emacs to retrieve the handle of its frame (windows to other GUI users) but in the meantime I've got settle for a way by which TPanel can obtain the handle of an object embedded in it.

The Tpanel.Components[] property contains a list of components on the Panel. Yoou can iterate that to find the component you need.

[marcov]

How do systems like X11 and Microsoft Windows distinguish between windows and controls?

A window are a handle that processes messages (can be non-visual).   A control has screen realestate somewhere.

I've come across a problem where after embedding a Emacs in a TPanel I am unable to get the Emacs to resize after resizing the TPanel, point being that X11 needs a different handle to the Emacs window itself.

Emacs is a cool OS, pity about the bad editor

[MarkMLl]

I've come across a problem where after embedding a Emacs in a TPanel I am unable to get the Emacs to resize after resizing the TPanel, point being that X11 needs a different handle to the Emacs window itself.

There must be a way of getting Emacs to retrieve the handle of its frame (windows to other GUI users) but in the meantime I've got settle for a way by which TPanel can obtain the handle of an object embedded in it.

I swear somebody was asking about this in a different thread just yesterday. This isn't about handles, it's about signals.

MarkMLl

[vfclists]

There must be a way of getting Emacs to retrieve the handle of its frame (windows to other GUI users) but in the meantime I've got settle for a way by which TPanel can obtain the handle of an object embedded in it.

The Tpanel.Components[] property contains a list of components on the Panel. Yoou can iterate that to find the component you need.

In this case the TPanel has no components on it. The embedded Emacs is passed the window handle of the TPanel and embeds itself directly in it.

There is probably some kind of "child" component there but whether it is accessible from the LCL code is another issue.

The code is something along these lines

Code for getting the panel's window handle.

Code: Pascal  [Select][+][-]

1. procedure TForm1.btnPanelHandleClick(Sender: TObject);
2. begin
3.   edtWinHandle.Text := IntToStr(QWidget_winId(TQtWidget(pnlEmacsParent.Handle).Widget));
4. end;
5.  

Emacs command, with window handle 102760473

Code: Bash  [Select][+][-]

1. emacs  --parent-id 102760473 --with-profile doom01
2.  

[vfclists]

How do systems like X11 and Microsoft Windows distinguish between windows and controls?

A window are a handle that processes messages (can be non-visual).   A control has screen realestate somewhere.

Can you give an LCL examples of this distinction?

Does this apply to both X11 and Windows?

I would have thought it would be the other way round, with something with visible screen estate being a window, and something handling events being the control. The usual mixed up terminology we get in CS.

[KodeZwerg]

How do systems like Microsoft Windows distinguish between windows and controls?

Code: Pascal  [Select][+][-]

1. uses
2.  Windows;
3.  
4. function HandleIsWindow(AHandle: HWND): Boolean;
5. begin
6.  Result := IsWindow(AHandle) <> 0;
7. end;

[marcov]

Can you give an LCL examples of this distinction?

Sure TWincontrol vs Forms.allocatehwnd.

[440bx]

How do systems like X11 and Microsoft Windows distinguish between windows and controls?

It seems to me that windows are what controls are placed in.

The following is strictly Windows only. 

In Windows, a control is a window with a predetermined function, e.g, edit, combobox, scrollbar, etc, etc. As such, the code that will process the message routed to it is already written (it is identified by the control class name.)

A non-control window, what could be considered a "normal window", is a container that may consist of other windows, such as controls or, non-windowed graphical elements, e.g, lines, curves, etc.  A crucial difference between the two is that, the code that processes messages and therefore determines the function of a non-control window must be programmer-written, IOW, it is not mostly (or entirely) "canned code" that can be identified by referring to a pre-existing class name. 

All of the above said, OOP libraries, such as those used in Lazarus, can blur the distinction between the two to some extent, making it a bit subjective as to what is a window and what is a control.

HTH.

[Joanna]

All of the above said, OOP libraries, such as those used in Lazarus, can blur the distinction between the two to some extent, making it a bit subjective as to what is a window and what is a control. 

In Lazarus I believe the twincontrol is a control which can contain other controls. Not all tcontrol descendants can do this of course

The only control that is an independent window is the tform afaik.