Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » About DHCtrl and window handles...
About DHCtrl and window handles... [message #12667] Mon, 12 November 2007 20:39 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Mon, 12 November 2007 07:02

luzr wrote on Mon, 12 November 2007 12:23


Well, the trouble is that this is (and has to be) platform specific.


Of course... but there is a thing that I don't like in Upp, and is that many platform specific methods are made public... I'd separate them from the public interface.



What is that supposed to solve? Smile

BTW, there are people suggest to me to make ALL methods public and virtual...

Quote:


Ok, but I don't understand if EventProc is called on each control for all Windows or not.



Normally, only to top-level Ctrls (GetParent() == NULL).

Of course, existing DHCtrl recieves them too. So better to say, to all windows with handles, but handles for non-top-level windows are yet to be implemented in X11, that is the important part of the task...

Quote:


- Both A and B once, with A as parameter
- Only to A, as B don't need repaint



EventProc is already redirected to the window with given handle, if that answers your question....

Quote:


And, second question, how does MainWindos's EventProc dispatch the message to windowless controls ?



Nope. Dispatching to windowless ctrls is already done by platform independent code. Platform depended ends at distributing top-level events.

Quote:


And to windowed ones ?



There is a map in X11 platform specific code that maps handles to Ctrl *.

Quote:


Again an example :
A is a top level window, and B is a child of A, but with window handle too. What happens if I click on B ?
- B gets the event directly, A gets nothing



In Win32 DHCtrl, this is the case.

Quote:


And, last question (sorry, but it's a complicated matter...), another example :
-A is a main window (with XWindow inside), B is a child of A (no matter if windowed or not...) and C is a child of B.



Hey, wait a moment. This is common misconception. Parentship is not the same thing as ownership.

All top-level widgets have no parents. Anyway, they can have owners.

Mirek
Re: About DHCtrl and window handles... [message #12669 is a reply to message #12667] Mon, 12 November 2007 21:03 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1358
Registered: December 2006
Ultimate Contributor
luzr wrote on Mon, 12 November 2007 14:39


BTW, there are people suggest to me to make ALL methods public and virtual...



That is the beginning of the end ... Wink


Regards,
Novo
Re: About DHCtrl and window handles... [message #12672 is a reply to message #12667] Mon, 12 November 2007 21:53 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Mon, 12 November 2007 20:39

mdelfede wrote on Mon, 12 November 2007 07:02

luzr wrote on Mon, 12 November 2007 12:23


Well, the trouble is that this is (and has to be) platform specific.


Of course... but there is a thing that I don't like in Upp, and is that many platform specific methods are made public... I'd separate them from the public interface.



What is that supposed to solve? Smile



Well, that should force derived controls to be platform-independent, if methods are made private, or at least that would force user code (not derived from Ctrl) to *not* use platform dependent stuffs.... IMHO those should be good reasons.
IMHO, core classes should incapsulate all platform dependent behaviour.

Quote:


BTW, there are people suggest to me to make ALL methods public and virtual...



Brrrrrrr ! Mad
So, if they don't bother of writing portable code, here's again the way :
#define private public
#include <all-Upp>

Very Happy
That's just for public, for 'virtual' I guess it's not so easy!

Quote:


Quote:


Ok, but I don't understand if EventProc is called on each control for all Windows or not.



Normally, only to top-level Ctrls (GetParent() == NULL).

Of course, existing DHCtrl recieves them too. So better to say, to all windows with handles, but handles for non-top-level windows are yet to be implemented in X11, that is the important part of the task...


So, as I'm trying to implement it (to some extents...), what I need to know is what happens now if I create an X11 handle on a child control, in respect with events.
I suppose X11 sends the event directly to window inside my control... so, my code *or* Upp has to have a way to handle the event, what is done usually in an event loop.
As you're keeping a list of X11 handles, I suppose that you've got a global event handler that dispatches in some way events to controls, right ? Because that's the central point... if Upp dispatches in some way the event, I must just catch it; if not, I must hook someway my code in your event loop... If I'm not making some big mistake, of course Smile

Quote:


Quote:


- Both A and B once, with A as parameter
- Only to A, as B don't need repaint



EventProc is already redirected to the window with given handle, if that answers your question....


Not completely... I understand that your code redirects events to correct control, but what I don't know is if your code catches ALL events or only mainwindows events.
Better explained, if I create an X11 window that overlap a control, you're saying that my X11 window gets the event directly ? does UPP receive it also and dispatch it ?
Is maybe that one the purpose of having a global list of X11 windows handles ?
.........
Quote:


Quote:


And to windowed ones ?



There is a map in X11 platform specific code that maps handles to Ctrl *.


Ok, so I guess I did understand right... it's the Xwindow()[] map, right ? So, if I hook my handle inside it, my control gets Events as usual non-windowed controls ?

Quote:


Quote:


Again an example :
A is a top level window, and B is a child of A, but with window handle too. What happens if I click on B ?
- B gets the event directly, A gets nothing



In Win32 DHCtrl, this is the case.


So, I guess I'll have to duplicate this behaviour.

Quote:


Quote:


And, last question (sorry, but it's a complicated matter...), another example :
-A is a main window (with XWindow inside), B is a child of A (no matter if windowed or not...) and C is a child of B.



Hey, wait a moment. This is common misconception. Parentship is not the same thing as ownership.

All top-level widgets have no parents. Anyway, they can have owners.



Yes, I know the difference....
A child is usually an included control (or at least a dependent control), ownership is related to create/destroy it, not to the appearance nor to event handling.

Well, I'll try to go a bit further with my X11_DHCtrl Razz

Ciao

Max

ops.... just another question :

Suppose this one :

MainWindow->A->B (-> represent Parent of)
B is windowed. I get the event... should I reflect to toplevel window ? I think that should the more consistent way to do the job...

Ciao

Max

Re: About DHCtrl and window handles... [message #12675 is a reply to message #12672] Mon, 12 November 2007 23:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Mon, 12 November 2007 15:53

luzr wrote on Mon, 12 November 2007 20:39

mdelfede wrote on Mon, 12 November 2007 07:02

luzr wrote on Mon, 12 November 2007 12:23


Well, the trouble is that this is (and has to be) platform specific.


Of course... but there is a thing that I don't like in Upp, and is that many platform specific methods are made public... I'd separate them from the public interface.



What is that supposed to solve? Smile



Well, that should force derived controls to be platform-independent, if methods are made private, or at least that would force user code (not derived from Ctrl) to *not* use platform dependent stuffs.... IMHO those should be good reasons.
IMHO, core classes should incapsulate all platform dependent behaviour.



IMO, that is the bad way how to do things. I am pretty sure that "#ifdef PLATFORM_WIN32" is enough warning for anybody planning to use it, no need to stay in a way if you really need to do platform specific stuff.

Quote:


Ok, so I guess I did understand right... it's the Xwindow()[] map, right ? So, if I hook my handle inside it, my control gets Events as usual non-windowed controls ?



I suppose so, but frankly, I never really studied child windows in X11 Smile

In any case, X11 returns a target handle. That determines the widget whose EventProc is about to be called...

Quote:


Yes, I know the difference....
A child is usually an included control (or at least a dependent control), ownership is related to create/destroy it, not to the appearance nor to event handling.



Nope (or yes, but you are quoting another context and non-U++ teminology).

Owned window is a top-level window that has related owner.

For example, Find dialog in ide is owned by the main ide window. Such Find dialog is owned but really does not have parent (its GetParent is NULL).

Quote:


MainWindow->A->B (-> represent Parent of)
B is windowed. I get the event... should I reflect to toplevel window ? I think that should the more consistent way to do the job...



No.

Mirek
Re: About DHCtrl and window handles... [message #12679 is a reply to message #12675] Mon, 12 November 2007 23:42 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Mon, 12 November 2007 23:21


Quote:


MainWindow->A->B (-> represent Parent of)
B is windowed. I get the event... should I reflect to toplevel window ? I think that should the more consistent way to do the job...



No.



Why not ? Confused
Doesn't TopWindow take care of dispatching events to various Ctrl virtual funcs (like paint...) ? The only other possibility I see is to reimplement all low level event dispatcher for my control... seems to me a bit nonsense.... Where am I wrong ?
Re: About DHCtrl and window handles... [message #12682 is a reply to message #12679] Tue, 13 November 2007 00:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Mon, 12 November 2007 17:42

luzr wrote on Mon, 12 November 2007 23:21


Quote:


MainWindow->A->B (-> represent Parent of)
B is windowed. I get the event... should I reflect to toplevel window ? I think that should the more consistent way to do the job...



No.



Why not ? Confused
Doesn't TopWindow take care of dispatching events to various Ctrl virtual funcs (like paint...) ? The only other possibility I see is to reimplement all low level event dispatcher for my control... seems to me a bit nonsense.... Where am I wrong ?


Well, standard EventProc leaves that to U++. The idea is to override WindowProc / EventProc, do you hooks and then call Ctrl::WindowProc/EventProc...

Anyway, I guess your control will be of special kind anyway (like GLCtrl).

Mirek
Re: About DHCtrl and window handles... [message #12684 is a reply to message #12682] Tue, 13 November 2007 00:47 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Tue, 13 November 2007 00:13



Anyway, I guess your control will be of special kind anyway (like GLCtrl).




Indeed Smile But I think It's going to work now !

Ciao

Max
Re: About DHCtrl and window handles... [message #12705 is a reply to message #12684] Tue, 13 November 2007 15:34 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
In order to avoid the need of make friends of GLCtrl all windowed x11 controls (and maybe it could serve for other purposes...)
I suggest to add these 2 protected members to GLCtrl :

/////////////////////////////////////////////////////////////////////////////////////////
// Add subwindow to upp list of Xwindows
void Ctrl::AddUppXWindow(Window &w)
{
	int i = Xwindow().Find(None);
	if(i >= 0)
		Xwindow().SetKey(i, w);
	XWindow& cw = i >= 0 ? Xwindow()[i] : Xwindow().Add(w);
	cw.ctrl    = this;
	cw.exposed = true;
	cw.owner   = GetParent();
	cw.xic     = NULL;

} // END Ctrl::AddUppXWindow()


/////////////////////////////////////////////////////////////////////////////////////////
// Removes subwindow to upp list of Xwindows
void Ctrl::RemoveUppXWindow(Window &w)
{
	int i = Xwindow().Find(w);
	if(i >= 0)
	{
		Xwindow().SetKey(i, None);
		Xwindow()[i].ctrl = NULL;
	}

} // END Ctrl::RemoveUppXWindow()


This code is duplicated both in X11 Topwindow AND in GLCtrl, and is coming in my windowed X11 control too...
BTW, after I finish my X11 DHCtrl, I guess it would be not bad to rewrite X11 GLCtrl part to be derived of it... I'm already doing it for testing purposes.

Ciao

Max

p.s.: I'm thinking again that the good behaviour for event handling should start from TopWindow parenting child controls and propagated to them. AFAIK now, as is DHCtrl done (and mine too...) the parent of a windowed child control *don't* have any knowledge of events going to the child, as opposite as normal controls... maybe that can cause problems, I don't know yet.

[Updated on: Tue, 13 November 2007 15:39]

Report message to a moderator

Re: About DHCtrl and window handles... [message #12722 is a reply to message #12705] Wed, 14 November 2007 10:47 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 13 November 2007 09:34

In order to avoid the need of make friends of GLCtrl all windowed x11 controls (and maybe it could serve for other purposes...)
I suggest to add these 2 protected members to GLCtrl :

/////////////////////////////////////////////////////////////////////////////////////////
// Add subwindow to upp list of Xwindows
void Ctrl::AddUppXWindow(Window &w)
{
	int i = Xwindow().Find(None);
	if(i >= 0)
		Xwindow().SetKey(i, w);
	XWindow& cw = i >= 0 ? Xwindow()[i] : Xwindow().Add(w);
	cw.ctrl    = this;
	cw.exposed = true;
	cw.owner   = GetParent();
	cw.xic     = NULL;

} // END Ctrl::AddUppXWindow()


/////////////////////////////////////////////////////////////////////////////////////////
// Removes subwindow to upp list of Xwindows
void Ctrl::RemoveUppXWindow(Window &w)
{
	int i = Xwindow().Find(w);
	if(i >= 0)
	{
		Xwindow().SetKey(i, None);
		Xwindow()[i].ctrl = NULL;
	}

} // END Ctrl::RemoveUppXWindow()


This code is duplicated both in X11 Topwindow AND in GLCtrl, and is coming in my windowed X11 control too...



OK, np, good idea, adding that now.

Quote:


BTW, after I finish my X11 DHCtrl, I guess it would be not bad to rewrite X11 GLCtrl part to be derived of it... I'm already doing it for testing purposes.



Agree.

Quote:


p.s.: I'm thinking again that the good behaviour for event handling should start from TopWindow parenting child controls and propagated to them. AFAIK now, as is DHCtrl done (and mine too...) the parent of a windowed child control *don't* have any knowledge of events going to the child, as opposite as normal controls... maybe that can cause problems, I don't know yet.



Hard to say. Anyway, IMO, interface-wise it should be arranged that at the end of EventProc, the widget will call DHCtrl::EvenProc, which will do the all required stuff....

Mirek
Re: About DHCtrl and window handles... [message #12732 is a reply to message #12722] Wed, 14 November 2007 15:21 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Wed, 14 November 2007 10:47


OK, np, good idea, adding that now.



good, so I'll remove my friend patch to Ctrlcore and fetch new sources.

Quote:


Quote:


BTW, after I finish my X11 DHCtrl, I guess it would be not bad to rewrite X11 GLCtrl part to be derived of it... I'm already doing it for testing purposes.



Agree.


The windowed control start working ok, and in parallel also the GLCtrl derived from it. I have just a question more : windowed controls (X11 & windows too) should not receive paint/mouse and so events if they are not initialized. Up to now, I resorted to add an isInitialized member to my DHCtrl, but then all code in event handlers should check it before painting/reacting, ecc.
There is not a flag already present in Ctrl class that can be used to automatize that ?
For example, I'd set a "no_event" flag in constructor of my dhctrl, and reset it after window is created. But then the core of Ctrl should look for such a flag and avoid sending events to the uninitialized ctrl. (at least, no paint events).

Quote:



Hard to say. Anyway, IMO, interface-wise it should be arranged that at the end of EventProc, the widget will call DHCtrl::EvenProc, which will do the all required stuff....



Ok, I'm yet trying to fully understand the event chain, so I can't thell much more on the subject.
What I've seen in some other framework is a main event handler for each control (It could be your EventProc) that is called BEFORE events are dispatched to the control, and that can suppress the dispatching of them, for example, or modify them.
From what I've seen in my code, even if I set Ctrl EventProc to do nothing or to eat all events those are still passed to Paint() function, for example (not yet checked for mouse events). It's normal ?

Ciao

Max
Re: About DHCtrl and window handles... [message #12761 is a reply to message #12732] Wed, 14 November 2007 22:18 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Quote:


The windowed control start working ok, and in parallel also the GLCtrl derived from it. I have just a question more : windowed controls (X11 & windows too) should not receive paint/mouse and so events if they are not initialized. Up to now, I resorted to add an isInitialized member to my DHCtrl, but then all code in event handlers should check it before painting/reacting, ecc.
There is not a flag already present in Ctrl class that can be used to automatize that ?
For example, I'd set a "no_event" flag in constructor of my dhctrl, and reset it after window is created. But then the core of Ctrl should look for such a flag and avoid sending events to the uninitialized ctrl. (at least, no paint events).



Search for "isopen" and "visible" in X11 code.

Quote:


Ok, I'm yet trying to fully understand the event chain, so I can't thell much more on the subject.
What I've seen in some other framework is a main event handler for each control (It could be your EventProc) that is called BEFORE events are dispatched to the control, and that can suppress the dispatching of them, for example, or modify them.
From what I've seen in my code, even if I set Ctrl EventProc to do nothing or to eat all events those are still passed to Paint() function, for example (not yet checked for mouse events). It's normal ?



IMO should not happen for your DHCtrl.

Otherwise, U++ really cares about top-level Ctrls only. Messages from these are passed to the library and all dispatching is performed by library (to normal, window-less widgets).

Mirek
Re: About DHCtrl and window handles... [message #12762 is a reply to message #12761] Wed, 14 November 2007 23:55 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
So far I've noticed one thing... I guess, it's not easy Smile

If I put an X11 windows inside my ctrl, the ctrl don't get Expose events, as it's covered by the X11 window... or, better said, it gets them very few times when I'm adjusting the window pos with ctrl pos (when event happens in the middle of operation).

So, better than putting the window in upp windows list, would maybe better hook a routine in global event handler that do the job.
maybe... not sure about it.

Max
Re: About DHCtrl and window handles... [message #12788 is a reply to message #12762] Fri, 16 November 2007 12:00 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Wed, 14 November 2007 17:55

So far I've noticed one thing... I guess, it's not easy Smile



Yes, I am afraid that sums it up pretty well Wink

Mirek
Re: About DHCtrl and window handles... [message #12794 is a reply to message #12788] Fri, 16 November 2007 16:50 Go to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Fri, 16 November 2007 12:00

mdelfede wrote on Wed, 14 November 2007 17:55

So far I've noticed one thing... I guess, it's not easy Smile



Yes, I am afraid that sums it up pretty well Wink

Mirek



Well, that was referred to "understanding upp ctrl core code", not to write the control. It would be already finished since some days, but I usually like to write good code, not to add a bunch of patches to make it work, which is what I´ve done at the beginning to see things working.
For now, I`ve the feeling that the ctrl class hierarchy could have taken advantage from a DHCtrl class from the beginning, being
Ctrl - DHCtrl - TopWindow

the logical one, putting in DHCtrl (both x11 and windows) the low level windows creation part. But it`s too late, I guess Smile

Ciao

Max
Previous Topic: SVN plan...
Next Topic: Interesting problem with setlocale
Goto Forum:
  


Current Time: Fri Mar 29 11:56:11 CET 2024

Total time taken to generate the page: 0.01686 seconds