|
|
Home » U++ Library support » U++ Widgets - General questions or Mixed problems » DockCtrl (A dockable window widget for U++)
|
Re: DockCtrl (A dockable window widget for U++) [message #11863 is a reply to message #11859] |
Fri, 28 September 2007 18:24 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
unodgs wrote on Fri, 28 September 2007 10:00 |
Quote: | Interesting, what xor rectangle?
|
Xor works perfectly if border of rectangle is 1 pixel width. If it is more than 1 pixel and you move rectnagle by 1 pixel for example rectangle must flicker - overlaping border parts are deleted and then repainted in the same position.
|
AFAIK not with
Quote: |
void DrawDragRect(Draw& w, const Rect& _rect1, const Rect& _rect2, const Rect& _clip, int n, Color color, uint64 pattern)
|
Search it in CtrlCore for usage, this should be flicker-free - it works by xoring only "new" parts of rectangle - overlapping parts are NOT deleted
Mirek
|
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11865 is a reply to message #11861] |
Fri, 28 September 2007 18:38 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
Oblivion wrote on Fri, 28 September 2007 10:49 |
By the way, Mirek why isn't there any "non-client area" event handler on U++? I couldn't find any. Did I miss something?
|
WindowProc?
Anyway, I am starting to feel a bit worried about all these platform specific tricks. I am not sure what exactly is covered by "docking windows", but I expected that most of it can be done using existing interfaces.
Quote: |
Well, U++ is like an Iceberg, almost everything is gone undocumented. Don't get me wrong, The actual U++ code is impressing; but lack of documentation really slows down the process, and maybe that is why some people think that it is only a gui widget collection (well, it is definitely not!)
|
Yes. You can start improving the situation by writing some docs
I am starting planning for the next year, theide / documentation will be the main focus.
Mirek
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11866 is a reply to message #11865] |
Fri, 28 September 2007 18:57 |
Oblivion
Messages: 1094 Registered: August 2007
|
Senior Contributor |
|
|
luzr wrote on Fri, 28 September 2007 19:38 |
Oblivion wrote on Fri, 28 September 2007 10:49 |
By the way, Mirek why isn't there any "non-client area" event handler on U++? I couldn't find any. Did I miss something?
|
WindowProc?
Anyway, I am starting to feel a bit worried about all these platform specific tricks. I am not sure what exactly is covered by "docking windows", but I expected that most of it can be done using existing interfaces.
Quote: |
Well, U++ is like an Iceberg, almost everything is gone undocumented. Don't get me wrong, The actual U++ code is impressing; but lack of documentation really slows down the process, and maybe that is why some people think that it is only a gui widget collection (well, it is definitely not!)
|
Yes. You can start improving the situation by writing some docs
I am starting planning for the next year, theide / documentation will be the main focus.
Mirek
|
YEs there is Windowproc, and I use it. What I meant with "nc handlers" was, methods to handle windowproc messages as in MFC. Anyway, it was only a suggestion
Well I think I exaggerated the situation a bit. I've managed to handle all those "tricks" I've mentioned before (including AjustWindowRect) in native U++. So you should'nt have to worry about them anymore Only the "Mousehook" remains. It only
handles WM_NCLBUTTONUP, and is needed because windows has a well known internal bug which they prefer to call "feature". So there is nothing much left to worry about. As I'd stated in the first post, it is and will be in U++ (except for the mouse hook). IMO, all those tricky things which I tried to implement couple of days ago are due to the lack of documentation (it takes time to find what i need).
Actually, I am working on documentation for DockCtrl. But my english, as you may have noticed, is far from being perfect And this is my "internal bug"
Regards
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Fri, 28 September 2007 19:03] Report message to a moderator
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11867 is a reply to message #11866] |
Fri, 28 September 2007 20:59 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
Oblivion wrote on Fri, 28 September 2007 12:57 |
It only
handles WM_NCLBUTTONUP, and is needed because windows has a well known internal bug which they prefer to call "feature".
|
Well, what is your need for WM_NCLBUTTONUP and what is the bug?
I believe that if there would be any problem, we should have noticed...
Quote: |
Actually, I am working on documentation for DockCtrl. But my english, as you may have noticed, is far from being perfect And this is my "internal bug"
Regards
|
As is mine. The content, at this phase, is much more imporant.
Mirek
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11868 is a reply to message #11867] |
Fri, 28 September 2007 21:40 |
Oblivion
Messages: 1094 Registered: August 2007
|
Senior Contributor |
|
|
luzr wrote on Fri, 28 September 2007 21:59 |
Well, what is your need for WM_NCLBUTTONUP and what is the bug?
|
Ok, let me explain. Dockwindows are basically derived from "DockableCtrl" class, which is actually a derivative of TopWindow. So it is possible to use it at the same time as a ctrl, and as a window. In their "docked state" they act as a ctrl and in their "float state" they are detached (dragged/teared) from their panes and activated as tool windows. When a dockwindow is teared off/dragged in solid window dragging(with the Dockablectrl::Float()/FloatEx method), it has to receive mouse messages immediately, because it is from then on in a "dragging state". This can be done easily by sending a fake WM_NCLBUTTONDOWN message with HTCAPTION parameter; by this command, system is faked to believe that mouse is dragging a "window" from it's titlebar. Here is the sequence.
1. Drag Dock from its "dragbar"(from the title bar of the dock)
This is done by LeftDrag(). So the left mouse is, from now on, "down"
2. Remove() dock from its pane.
3. Open it as a child toolwindow under the cursor position.
4. Immediately Send a WM_NCLBUTTONDOWN message explicitly (with HTCAPTION as wparam). (because, the Lmousebutton is still down.)
5. Move window.
6. Drop (theoretically, the window should send WM_NCLBUTTONUP so we could get the drag/drop state, but it doesnt; so we use the mouse patch we already installed when we invoke the Float() command and send the WM_NCLBUTTONUP command manually).
This is the actual tear-off/drag sequence.
(As you can see this in the executable example (0.49.7a) I've posted. This is how a solid window drag sequence can be made possible on Win32, Or maybe I don't know the way, ayn suggestions will be very useful). But unfortunately windows from XP on does not send the proper WM_NCLBUTTONUP message to the window's message pump when the left button is released on the NC area! So it couldn't "drop" at first time when mouse button is released. It is clearly stated in the MSDN that it does, but in fact it doesn't. It is a well known bug/behaviour.
So as you see, in this case the standard U++ leftup or leftdown won't work because those messages only handle AFAIK the client area. Is there something I don't know about it?
Here is the problem and the hook solution is explained:
http://www.codeguru.com/cpp/misc/misc/windowsmessaging/artic le.php/c3885/
I use a modified version of this mouse hook, So the article could give you a clear idea about the problem, solution and (hopefully) a better solution suggestion from you
Here is the modified code
//======================================================
// Original code by Robert Wiejak, (c) 2001.
//
//
#ifdef PLATFORM_WIN32
LRESULT DockCtrl::Win32MessagePatch(int code, WPARAM wParam, LPARAM lParam)
{
if(code == 0)
{
PMOUSEHOOKSTRUCT mousehookstruct = (PMOUSEHOOKSTRUCT) lParam;
DockableCtrl* dock = ::__dctrlptr->ptr->FindDockWindow(mousehookstruct->hwnd);
{
switch(wParam)
{
case WM_NCLBUTTONDOWN:
if(dock && mousehookstruct->wHitTestCode == HTCAPTION) dock->Dragging(TRUE);
break;
case WM_NCLBUTTONUP:
if(dock) dock->Dragging(FALSE);
break;
case WM_LBUTTONUP:
{
DockableCtrl *target = NULL;
if(dock && dock->IsDragged()) target = dock;
else
target = ::__dctrlptr->ptr->FindDraggedWindow();
if(target)
{
::PostMessage(target->GetHWND(), WM_NCLBUTTONUP, HTCAPTION, MAKELONG(mousehookstruct->pt.x, mousehookstruct->pt.y));
target->Dragging(FALSE);
}
}
break;
default:
break;
}
}
}
//===============================================
Regards.
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Fri, 28 September 2007 22:24] Report message to a moderator
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11869 is a reply to message #11868] |
Fri, 28 September 2007 22:09 |
|
mirek
Messages: 13984 Registered: November 2005
|
Ultimate Member |
|
|
I see, thanks.
I think you can find this article useful:
http://slingkid.blogsome.com/
Quote: |
The trick in asking the OS to resize a window is sending the window a WM_SYSCOMMAND message. The following are parameters you pass in the message to specify how the window should be resized.
public const int SC_DRAGMOVE = 0xF012;
public const int SC_DRAGSIZE_N = 0xF003;
public const int SC_DRAGSIZE_S = 0xF006;
public const int SC_DRAGSIZE_E = 0xF002;
public const int SC_DRAGSIZE_W = 0xF001;
public const int SC_DRAGSIZE_NW = 0xF004;
public const int SC_DRAGSIZE_NE = 0xF005;
public const int SC_DRAGSIZE_SW = 0xF007;
public const int SC_DRAGSIZE_SE = 0xF008;
Usually, in your OnMouseDown method, you would delegate the job of resizing to ths OS. The code below does just that.
|
We are already using this in U++ - look at
void SizeGrip::LeftDown(Point p, dword flags)
It seems to work well on all platforms.
I believe that using SC_DRAGMOVE = 0xF012 instead of 0xf008 should solve your problem...
In the same function, there is also X11 implementation, based on
http://standards.freedesktop.org/wm-spec/1.3/ar01s04.html
As you can see, replacing
should do the trick for X11...
Mirek
(BTW, it perhaps might be useful to make this more public in CtrlCore).
[Updated on: Fri, 28 September 2007 22:11] Report message to a moderator
|
|
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11872 is a reply to message #11870] |
Sat, 29 September 2007 00:15 |
mrjt
Messages: 705 Registered: March 2007 Location: London
|
Contributor |
|
|
I've been working on something similar (I've been off the net for two weeks or I would have said something sooner), and I'm sending the WM_NCLBUTTONDOWN message in the same way. I get around it like this:
if (message == WM_WINDOWPOSCHANGING && !IsDocked() && !GetMouseLeft())
// Dragging finished
(IsDocked() is mine, GetMouseLeft() is UPP)
Fortunately this is almost the only hack I've had to use, the rest is all UPP.
I've attached a demo compiled with MingW (which seems much less stable than the MSC version, annoyingly). As you can see I've still got some considerable bugs to work out myself I've only just managed to get autohide mostly working but the Splitters need some serious attention to get them to resize correctly.
I'm not quite ready to publish all of the code (too scared!), but let me know if I can help. It's a very interesting project.
James
PS. Oddly, one of the things I've had the most trouble with (except the bloody autohiding!) is the title bar on docked windows. I've ended up using some really ugly code and a FrameCtrl. How do yours work?
Edit: Exe is for Win32 only, and I've only tested it on XP so I wouldn't be suprised if it crashes horribly on Vista. You have been warned
-
Attachment: DockTest.exe
(Size: 957.00KB, Downloaded 908 times)
[Updated on: Mon, 01 October 2007 10:51] Report message to a moderator
|
|
|
|
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11879 is a reply to message #11876] |
Sat, 29 September 2007 11:11 |
Oblivion
Messages: 1094 Registered: August 2007
|
Senior Contributor |
|
|
luzr wrote on Sat, 29 September 2007 09:42 |
Oblivion wrote on Fri, 28 September 2007 18:43 |
As for the titlebar, I use a "DragBar" class, which is derived from both Ctrl and CtrlFrame as well. It is a nested class and it differs in implementation for DockWindow and DockBar (Rebar like widget). And almost every event is handled through it. DockWindow is activated only when it is in floating state.
|
Beware.
In X11, you cannot use popup windows (I mean, windows without decorations) as main windows.
Consult this for available types:
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id 2507144
(I guess some experimenting will be needed....)
Mirek
|
Hmm, I've read the specifications, what about the _NET_WM_WINDOW_TYPE_TOOLBAR type? Dockwindows are not popups and they are already child windows, so there shouldn't be any problem for them. As for the planned (after I achieve a full featured dockctrl) "DockBar," it is not going to be a "main" window either. Is it not possible to use "child" windows in X11 (I know that terminology differs in X11 due to the conceptualization of it's client-server system, but I'm not a X11 guru)
And I agree. I guess It's time for me to install a linux distro
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Sat, 29 September 2007 11:15] Report message to a moderator
|
|
|
|
Re: DockCtrl (A dockable window widget for U++) [message #11995 is a reply to message #11994] |
Sun, 07 October 2007 09:43 |
|
Oblivion wrote on Sat, 06 October 2007 20:52 | Ok, here is the new executable.
I've added basic QT-like DnD animation. Finally I've got my hands on two linux distros (Ubuntu-Beryl and Pardus (Turkish)). So I hope that I will release a X11 based exe in coming weeks. (I didn't have the time to install them. (I'll do it probably this week).
|
Hi! Very impressive! It's almost what I was thinking of (those cool qt animations can be added at the very end). The only missing thing now is tabbed panel and I wonder how tabs should look like. Should they have native look (then you could use tabctrl code to render tabs) or custom one. I think native will be better. Anyway don't stop coding Results are great!
|
|
|
|
|
Goto Forum:
Current Time: Sat Jun 08 08:35:38 CEST 2024
Total time taken to generate the page: 0.01580 seconds
|
|
|