I am doing some experiments with detachable tabs in the gb.form.mdi component.  
A couple of things have come to light that I would like to suggest (as a basis 
for discussion, rather than a bug or whatever).

1) There is no way to completely detach a window from a workspace. 
That is, for example: suppose I have two workspaces on a form (or to abstract 
even further perhaps two workspaces on two concurrently active forms) and I 
want to move the current tab from this workspace to that workspace. I have 
proved I can do that almost successfully by, to put it at its' simplest:
  Workspace1.Detach(hWindow)
  Workspace2.Add(hWindow)
but the association with Workspace1 remains and has some interesting side 
effects.
So, it appears (to me) there is no way to completely dissociate hWindow from 
its' original Workspace.

2) When a window is Attached to a Workspace it is not automatically made the 
ActiveWindow.
This may be "by design" but if I want to make the ActiveWindow in code then 
there does not seem to be anything like an "Attached" event in the Workspace 
that I can catch to effectively make this automatic Activation happen.
(I have found a reasonably simple workaround for this but it is not 
"intuitively obvious".

3) Similar to 2) there is no "Detached" event available whereby I could set 
some values in the Workspace concerned or even in the detached window that 
would allow me to affect later processing.  That's obscure.  Suppose I have, as 
above, two workspaces and when I detach a window from one I need to know later 
"which workspace it was detached from", it would be nice to say set the Tag 
property to the name of the "original workspace".  Either...

3a) Because I would like to implement a menuitem in the detached window that 
would allow a "Re-attach" action.
3b) Because  even when the window is detached I may like to Reparent it in some 
other container .... :-) tricky eh?

4) The Detach/Attach/Reparent methods are not exactly ... how can I say it .... 
developer friendly?
Suppose I want to move a window from a workspace to some other container.  When 
the window is associated with a workspace, ReParent does not work - and 
silently at that.  The window must first be detached and then reparented.  
Conversely, moving it from another container to a workspace involves a (fake) 
reparent, then either a Workspace.Add or, given that there is no completely 
detach method, a Workspace.Attach call.

As I said, these things are not really bugs or complaints, rather a "Request 
For Comment".  I have a demo project displaying some of these things which I 
will post if there is some interest.

But, imagine an IDE wherein you could have both the form design and the form 
code visible at the same time in an hsplitter, or where you could have two (or 
more) class codes visible at the same time, or the ability to move one of the 
"bits" of the properties tab to the bottom "debug" panel of the IDE, or even 
move the toolbox into a vsplitter under the project browser instead of having 
it clutter the bottom of the properties sidepanel ... or even for that matter 
moving the properties thing into the middle pane... or or or. Get my drift?

Anyone familiar with, for example, how the Modellio layouts can be manipulated 
in this way will understand what could be achieved here for the gambas IDE.

regards and looking forward to comments
Bruce 

-- 
B Bruen <bbr...@paddys-hill.net>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user

Reply via email to