Flying panel/toolbar/form (like Office toolbar)

[JuhaManninen]

Out of curiosity I enabled the info box on the inspector and in my installation the only think that I see when the popupMode or popupParent is selected is one line on top that reads "Package LCLBase" nothing else is provided I'm guessing that you are using a trunc version or something is wrong with my installation.

Yes, I forgot to mention I use trunk. I guess somebody documented PopupMode but did not know what it does.
Lazarus trunk and the new 1.2 release branch have the OI info box visible by default. The info is more readable because useless headers are removed. A user can see the essential text without scrolling.

I recommend for everybody to test the new branch
  http://svn.freepascal.org/svn/lazarus/branches/fixes_1_2
or the 1.1.99 Pre Release or the future 1.2RC releases, so we can weed out bugs and final 1.2 will be perfect. (!)

Really? On my 1.0.10 lazarus I can select any form in the project as a popupParent.

Ok, another bug. May be because of this change:
  http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TComponentPropertyEditor_behavior_was_changed
I made the change so I guess I must fix it, too.

I do not have any idea on what the "component palette pages popup window" is, although I have used codeTyphoon for a sort period of time when I was starting I can't visualize what you are talking about or where to find it in lazarus 1.0.10.

CodeTyphon has a big arrow on the right side of component palette. We changed it for a smaller and less striking arrow, and Martin placed it inside the palette itself. It is rather nice now.

[taazz]

Yes, I forgot to mention I use trunk. I guess somebody documented PopupMode but did not know what it does.
Lazarus trunk and the new 1.2 release branch have the OI info box visible by default. The info is more readable because useless headers are removed. A user can see the essential text without scrolling.

I recommend for everybody to test the new branch
  http://svn.freepascal.org/svn/lazarus/branches/fixes_1_2
or the 1.1.99 Pre Release or the future 1.2RC releases, so we can weed out bugs and final 1.2 will be perfect. (!)

I'll try to find some time on this if there is an official list of things to be tested I could spend some time reporting problems or irritating things on those as well.

Ok, another bug. May be because of this change:
  http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TComponentPropertyEditor_behavior_was_changed
I made the change so I guess I must fix it, too.

Well the problem as I see it, is that a working piece of code was changed with out any regard on backward compatibility and with out any knowledge on what it will affect, I would simply add a new property on the existing property editor allowing to distinguish between global or local component list and I wouldn't split it to 2 components in the first place. Breaking working functionality like these it should be considered a taboo and allowed only when there is no other way around the problem. 

CodeTyphon has a big arrow on the right side of component palette. We changed it for a smaller and less striking arrow, and Martin placed it inside the palette itself. It is rather nice now.

Ah yes now I remember I used it on CodeTyphoon and I even wished that lazarus had it when I settled on it but after finding the shift+Ctrl+P combination I never missed it again.

I'm going to take a look on the functionality and see if I can spot the problem of "not closing" that you mentioned when I install the 1.1.99 or the RC later on.

[JuhaManninen]

Well the problem as I see it, is that a working piece of code was changed with out any regard on backward compatibility and with out any knowledge on what it will affect,

The bug now was a false alarm. I tested with Lazarus forms that were not part of the project. I get a list of all project forms now.
I had "knowledge on what it will affect". I checked all uses of TComponentPropertyEditor and changed the ones that needed changing, while fixing a bug for ActiveControl property.
It is true I changed the behavior of an existing editor which was not necessary. Now I changed it back, the other editor is now called TComponentOneFormPropertyEditor.
This change will be merged to 1.2 and I removed the note from wiki for 1.2 changes.

I would simply add a new property on the existing property editor allowing to distinguish between global or local component list and I wouldn't split it to 2 components in the first place.

Please see ideintf/propedits.pp about how the editors must be made.

Breaking working functionality like these it should be considered a taboo and allowed only when there is no other way around the problem. 

I mainly fixed a bug. My assumption was that most use cases need my new editor and thus it will solve even more bugs. Maybe this assumption was wrong, dunno.

Juha

[taazz]

Erm, don't get me wrong I do not criticize your way of working or anything. Knowing nothing about the actual internal workings of LCL my rants are more like a "note to self" kind of thing that I publicize in order to get feedback rather than a "you shouldn't have done that" kind of attitude. Every point I make is been noted to a list of mine that I usually look at when I'm confused about things than anything else. Feedback from the community help me refine those points to a more complete "solution".

I'll take closer look at propedits.pp to see what is going on thank you for the heads up.

[JuhaManninen]

No worries. It is good to be critical.

One more thing about the info box in Object Inspector:
It becomes still more usable when TurboPowerIProDsgn package is installed. You get HTML formatting and links to units and packages etc.

I was hoping it could be installed by default for Lazarus 1.2. Unfortunately with GTK2 TurboPowerIProDsgn creates an access violation sometimes when moving mouse over editor hints. That's why it cannot be installed by default.
With other widgetsets it behaves OK.
See :
  http://bugs.freepascal.org/view.php?id=20202
It is a nasty bug. If somebody find a way to fix it, great.

[x2nie]

Hi guys...!

I have a small good news.
I am in a half work of creating a toolbar (different with Lazarus toolbar).

• Based on Toolbar97 by Jordan Russel
• Multiple toolbar in one row, also can be Full one row
• Toolbar position can be moved, drag/drop
• Has drag area (similar to TCoolbar does, but actually is Toolbar97's feature)
  In previous trial, I have failed for several times. So, I am happy I could did it.
• Floating toolbar is currently Windows only. and is buggy
• Show popup menu as a dropdown menu (similar to what TToobutton can do). It is Toolbar97 feature.
• Could not show any other flying panel currently. I hope it will be a basic of what TBX by Alex Denisov could did, perhaps in future.

I will upload here in next days, if anybody need the source-code.

I have problems:

• How to draw window caption (like any TForm caption&close button area) using Lazarus.
  I mean, not for Windows only. Is there a cross-platform way to paint header form ?
• Currently I use directly header form by setting BorderStyle := bsDialog for floating toolbar.
  But then, the form could not be docked automatically.
  Only by dragging the flying-toolbar it self (not by draggint the caption of form), it could be docked automatically when moved over a TTBDock.
  So, we can not use the caption area directly.
  We must set BorderStyle := bsNone, and Painting the caption area by ourself to simulate the "TDialog" 's  caption area, and user may move the flying toolbar by dragging that caption area which is actually is the toolbar itself.
• My big problem is how to replace the off-screen drag-zone-box, with the "alpha-blend-blue-zone" that is Lazarus could did when docking/undocking. ?
  When you docking / drag-undocking a form, Lazarus show us that blue-box-alphablended. Where is the code of this features in Lazarus source code? what unit.pas it is? which line number?
  

=============================
Okay, here is so far my summary of work:
* Argue that flying panel is realistic idea : I were showing the screenshoot of GTKx & QT's Flying panel in action. I am sure we could do it!
* Create flying panel demo: done, attached in previous post of this topic.
* Cross-platform flying form: we could use TForm.PopupParent
* Useful / general purpose flying panel : suspended, pending. due my minimum widgetset knowledge
* Flying toolbar : in progress, based on TB97 components. I decrease dependency to Windows.pas, not at all yet.
* Cross-platform skinned toolbar like TBX / SPTBX: planned, need your help.

 

[taazz]

well the following wiki page explains the window caption bar problem well enough http://wiki.freepascal.org/Docking#Drag_and_Drop.

My preference would be to change the underline lcl classes to mimic the windows behavior but I do not know how hard it will be to do so on GTK and QT although in QT I imagine it would be easier.

[x2nie]

Okay, Tazz..
I replacing the off-screen-box (paint to screenDC) with a TForm, a semitransparent TForm since I think Lazarus use it while in drag-dock operation.

My problem is: That semi-transparent form doesn't moved when I start drag the toolbar.
The problem is because I replace the message loop with application.message.
Okay, maybe I were wrong. It is better if I could use DRagImageList.
I just unluckly could not find any complete sample of using DragImageList, so I create that TForm for simulate the DragImagelist, due I think it is for crossplatform purpose.

Now, I need similar functions belows without explicitely uses Windows.pas :

• GetMessage()
• PostQuitMessage()
• TranslateMessage (Msg);
• DispatchMessage (Msg);

Any idea?

Here is the code:

Code: [Select]

{ Stay in message loop until capture is lost. Capture is removed either
          by this procedure manually doing it, or by an outside influence (like
          a message box or menu popping up) }
        while GetCapture = Handle do begin
          {$IFDEF FPC}
            Application.ProcessMessages;
          {$ELSE}
          case Integer(GetMessage(Msg, 0, 0, 0)) of
            -1: Break; { if GetMessage failed }
            0: begin
                 { Repost WM_QUIT messages }
                 PostQuitMessage (Msg.WParam);
                 Break;
               end;
          end;

          case Msg.Message of
            WM_KEYDOWN, WM_KEYUP:
              { Ignore all keystrokes while dragging. But process Ctrl and Escape }
              case Msg.WParam of
                VK_CONTROL:
                  if PreventDocking <> (Msg.Message = WM_KEYDOWN) then begin
                    PreventDocking := Msg.Message = WM_KEYDOWN;
                    MouseMoved;
                  end;
                VK_ESCAPE:
                  Break;
              end;
            WM_MOUSEMOVE:
              { Note to self: WM_MOUSEMOVE messages should never be dispatched
                here to ensure no hints get shown during the drag process }
              MouseMoved;
            WM_LBUTTONDOWN, WM_LBUTTONDBLCLK:
              { Make sure it doesn't begin another loop }
              Break;
            WM_LBUTTONUP: begin
                Accept := True;
                Break;
              end;
            WM_RBUTTONDOWN..WM_MBUTTONDBLCLK:
              { Ignore all other mouse up/down messages }
              ;
          else
            TranslateMessage (Msg);
            DispatchMessage (Msg);
          end;
          {$ENDIF}
        end;
edited: add screeshoot.
screenshoot: I am moving the "fuchsia toolbar" far somewhere in screen. But the offscreen form (dragimagelist simulation) is not moving anyewhere.

secondary screenshoot: the "fuchsia toolbar" moved, and dragged again (when running under Delphi)

[x2nie]

I will back, I need to care about the license first.

Halo!

For flying ghost, I have solved it.
I mean, for simulating the DragImage, now it is also moving when we move the toolbar anywhere.

(code is Attached below, when you are logged in).

=========
Story continue....

My current problem is when I set the "RowMin" property to higher of 1. (such RowMin := 2)
Oh, to re-generate the problem, you might need to several toolbar in one dock-bar,
and try to resize the form! 

When we can achieve it, at least we can make a (branch of) Lazarus that mimic the Delphi7 appearance:
draggable toolbars!

I hope you like it.

[Graeme]

If you project isn't too far already, maybe you can switch to fpGUI Toolkit [1].  In fpGUI there is a TfpgPopupWindow [2] class which does just want you want and works cross platform. It can popup, but you can also prevent it from stealing focus. In fact, that is how fpGUI implements Hints, Splashscreens, ComboBox dropdown, CalendarCombo dropdown etc.


1. http://fpgui.sourceforge.net/
2. http://fpgui.sourceforge.net/apidocs/fpg_popupwindow/tfpgpopupwindow.html

[x2nie]

If you project isn't too far already, maybe you can switch to fpGUI Toolkit [1].

Wow.!  First, I am glad meet you here, because I am learning fpGUI since days ago..
I am surprised by you Graeme.

No, it's not too far yet.
Currently my toolbar is inherited from TCustomPaintBox32 (Graphics32)  for handling cross-platform surface.
So, it should work together with QT,GK,Carbon (and any widgetset supported by GR32).
But my toolbar doesn't intensively depends on GR32.
Because of the appearance is low priority for me, so I leave it as still using TCanvas (which is provided internally by GR32) operation as also original toolbar97 did.

In fpGUI there is a TfpgPopupWindow [2] class which does just want you want and works cross platform. It can popup, but you can also prevent it from stealing focus. In fact, that is how fpGUI implements Hints, Splashscreens, ComboBox dropdown, CalendarCombo dropdown etc.

You might want to say: "..wich does just what you want.."
Yeah! that is what I wanted.
Okay, I will take this challenge In separated different purpose.

For combining of using fpGUI in my toolbar with general purpose, I have question, Graeme:
When I have switched my toolbar to support fpGUI Toolkit only, could I attach this toolbar into Lazarus IDE ?

If I could not, no problem. I still want to try switch it to fpGUI.
I just wonder if I were able. 

=========================
For current progress of flying toolbar, in case you want to know,
I am thinking (give me time) about the license of the library.
I preserve it would released under MPL/LGPLv2 as GR32's license, or as same as LCL license...
Since the original toolbar97 doesn't choose any lincense explicitely. TB97 author said it is opensource.

[Graeme]

Wow.!  First, I am glad meet you here, because I am learning fpGUI since days ago..
I am surprised by you Graeme.

Hidden gems are wonderful! 

For combining of using fpGUI in my toolbar with general purpose, I have question, Graeme:
When I have switched my toolbar to support fpGUI Toolkit only, could I attach this toolbar into Lazarus IDE ?

You cannot mix LCL and fpGUI components in the same application.

[x2nie]

Hi all..


It was long time (1 year ago) vacuum no progress so far since I wanted to implement flying toolbar, ...
and It was accidently I lost my laptop with the all source code I have, including the source of that  toolbar.
(see http://forum.lazarus.freepascal.org/index.php/topic,23775.msg142435.html)


I am glad,
Today, luckily I found that source-code, not the last, just an early work one.
But it run well with Lazarus 1.2.6


I am too happy, so I just upload it here as is, without modifying.
Please don't expect too much, for now, I will improve it later.
It require GR32 package to compile, I will remove it next day.


I just, too happy    (you know what I mean, remember when you lost your stuff and then found it back)
--------------------


The license would be LGPL 2.1 With linking exception, /+ / MPL 1.1


Enjoy!


=x2nie=