View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005271 | JEDI VCL | 00 JVCL Components | public | 2010-06-27 10:38 | 2012-09-13 09:06 |
Reporter | realart | Assigned To | wpostma416 | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | confirmed | Resolution | reopened | ||
Product Version | 3.38 | ||||
Target Version | Fixed in Version | ||||
Summary | 0005271: Bug in TJvDockServer, TJvDockClient | ||||
Description | === BUG in TJvDockServer, TJvDockClient === When we trying to dock OTHER dockable components (e.g. ToolBar) on a DockPanel (property of a DockServer), we have ACCESS VIOLATION error message (everytime). Other problem: standard (and Jv_ also) ToolBar do not have visible caption when its docked on a DockPanel. Thanks, Vitaly | ||||
Tags | No tags attached. | ||||
|
Please try with the very latest SVN content and let us know how this goes. If it does not solve your problem, please provide the zipped sources of a sample application showing the issue |
2010-06-28 18:48
|
Delphi.JEDI.Docking.7z (2,966 bytes) |
|
I attach 7Zip-file with a simple example: main form, TJvDockServer component, Toolbar. P.S. Sorry for my English (I'm ukrainian, speaking russian :) |
|
Also: 'SVN' - what is this? |
|
http://wiki.delphi-jedi.org/index.php?title=Source_Code_Repository |
|
sorry for disturb, but we want to know about problem |
|
Problem resolved? |
|
JvDocking only works with forms containing the JvDockClient component. What you are trying to do is not supported. |
|
to Kiriakos: that's right, but user everytime get a message 'ACCESS VIOLATION'. That is not solution of problem |
|
Well, you are saying you get an AV and Kiriakos kindly tells you that you MUST use a form with a JvDockClient Then you come back and say that you know, but still don't want to do it and want it to work without the required component. There is no solution here, you MUST use a form with a JvDockClient Anything else is unsupported and no change will be made to support that. Or maybe I did not understand your last answer... |
|
Just tried last SVN with XE2. MainForm has DockServer and some DockStyle but not DockClient. The effect is that when i move the MainForm it only shows window border rect a la Win 3.1 and feels heavy and slow (no CPU spikes, but the frame only catches up to mouse position about 1 time per sec. That feels like very slow and overloaded computer) Frankly, it seems strange. Why having DockServer on the form should affect it's own drag'n'drop. About AV there is the point. http://wiki.delphi-jedi.org/wiki/JVCL_Help:TJvDockServer claims dock server only accepts forms and only accepts forms having dockclient component on them. Then why does it accept ToolBar which is 1) not form 2) does not have JvDockClient as its child 3) event the Toolbar's parent (MainForm itself) does not have JvDockClient on it. There are also a lot of rendering quirks (but i have 120DPI fonts that Delphi has troubles with), but i guess that is minor issue. To me it boils down to simple question: Which objects should JvDockServer accept ? If it is designed to only accept Forms - then accepting ToolBar is patently wrong. You can hardly disable user to do any kind of stupid things (and frankly, dragging toolbar to another dock does not seem stupid, it is normal in many applications). If the dock accepts something - it should also release it fine. If the dock cannot correctly work with something - then it should not accept it. |
|
the framework is awfully complex yet i think that TJvDockCustomControl should override TWinControl.GetSiteInfo This should check if there is DockManager. If there is - then it should check if it is JvDockManager If it is not - then it should set CanDock to false; Otherwise he should either delegate decision to inherited TWinControl.GetSiteInfo, or to JvDockManager.DoCustomGetSeiteIngo |
|
This particular issue seems to be resolved by few changes. However i cannot understand the original idea of framework author and if that fits his intention or not. This also shows rendering artefacts in XE2 while dragging toolbars, but that is probably another unrelated thing. ---------- unit JvDockSupportControl; .... TJvDockCustomControl = class(TJvCustomControl) .... protected procedure GetSiteInfo(Client: TControl; var InfluenceRect: TRect; MousePos: TPoint; var CanDock: Boolean); override; ........... function TJvDockCustomControl.GetJvDockManager: IJvDockManager; begin // Result := IJvDockManager(DockManager); Result := nil; DockManager.QueryInterface(IJvDockManager, Result); end; procedure TJvDockCustomControl.GetSiteInfo(Client: TControl; var InfluenceRect: TRect; MousePos: TPoint; var CanDock: Boolean); var jdm: IJvDockManager; idm: IDockManager; begin idm := DockManager; if idm <> nil then idm.QueryInterface(IJvDockManager, jdm); if nil = jdm then CanDock := false else jdm.GetSiteInfo(Client,InfluenceRect, MousePos, CanDock); end; =============================== unit JvDockTree; ..... procedure TJvDockTree.GetSiteInfo(Client: TControl; var InfluenceRect: TRect; MousePos: TPoint; var CanDock: Boolean); begin CanDock := IsDockable(DockSite, Client); If CanDock then begin GetWindowRect(DockSite.Handle, InfluenceRect); InflateRect(InfluenceRect, DefExpandoRect, DefExpandoRect); end; end; |
|
I will fix this, and review Ariochs suggestion. I don't think JvDocking was meant to handle anything but a TForm that contains a TJvDockClient. I don't promise to make it work perfectly, but I will fix access violations. W |
|
To my view, JvDocking framework is stunningly complex. Without comments hard to understand all the intentions, but it looks kinda overengineered. Maybe it is full of non-complete features. Or just too many design patterns. Yet "support/not" check is done by one global function. That function is called by JvDockManager. But since VCL has it's own d'n'd - then it can happen w/o JvDockManager. That is what i tried to block with my proposal. JVCL knows how to do their docking, VCL knows about theirs. And they just should be kept separate. |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-06-27 10:38 | realart | New Issue | |
2010-06-28 13:28 | obones | Note Added: 0017518 | |
2010-06-28 13:28 | obones | Status | new => feedback |
2010-06-28 18:48 | realart | File Added: Delphi.JEDI.Docking.7z | |
2010-06-28 18:50 | realart | Note Added: 0017519 | |
2010-06-28 18:51 | realart | Note Added: 0017520 | |
2010-06-29 09:07 | obones | Note Added: 0017521 | |
2010-08-02 15:24 | realart | Note Added: 0017544 | |
2010-09-02 14:38 | realart | Note Added: 0017636 | |
2010-09-16 22:27 | Kiriakos | Note Added: 0017682 | |
2010-09-24 15:29 | realart | Note Added: 0017708 | |
2010-09-24 16:02 | obones | Note Added: 0017709 | |
2010-10-08 16:39 | obones | Status | feedback => resolved |
2010-10-08 16:39 | obones | Resolution | open => not fixable |
2010-10-08 16:39 | obones | Assigned To | => obones |
2012-08-31 15:23 | Arioch | Note Added: 0020140 | |
2012-08-31 15:23 | Arioch | Status | resolved => feedback |
2012-08-31 15:23 | Arioch | Resolution | not fixable => reopened |
2012-08-31 15:28 | Arioch | Relationship added | parent of 0005974 |
2012-08-31 18:31 | Arioch | Note Added: 0020145 | |
2012-08-31 18:32 | Arioch | Note Edited: 0020145 | |
2012-09-03 11:39 | Arioch | Note Added: 0020155 | |
2012-09-07 14:28 | Arioch | Status | feedback => confirmed |
2012-09-13 03:04 | wpostma416 | Assigned To | obones => wpostma416 |
2012-09-13 03:05 | wpostma416 | Note Added: 0020185 | |
2012-09-13 09:06 | Arioch | Note Added: 0020186 | |
2012-09-13 09:06 | Arioch | Note Edited: 0020186 | |
2012-09-13 09:06 | Arioch | Note Edited: 0020186 |