[Lazarus] First steps

Hans-Peter Diettrich DrDiettrich1 at aol.com
Tue Dec 9 23:23:43 CET 2008


Mattias Gärtner schrieb:

>> No. When a GUI program is started in the IDE, the designed forms stay on
>> the desktop and are overlaid when the windows are created by the
>> application. Moving the runtime form reveals the designtime form, what's
>> very confusing.
> 
> I see.
> At the moment there are only two choices: nothing, and hide all IDE windows.

On reaching an breakpoint all the windows will be restored :-(

> You want to hide only the designer forms. Probably the OI and the anchor editor
> should be hidden in that case too.

Right. The Delphi option is "Hide designer windows on run".

> Either the checkbox should be replaced with a radiogroup or with a checkgroup.

Or an additional checkbox in the designer options tab?

The GUI can be changed easily, but the functionality should be 
implemented ASAP.


>>> No docking at design time.
>> Then it should be properly disabled. As a workaround I leave the
>> designed mode as dmManual, and turn it into dmAutomatic in FormCreate -
>> but that's not a solution to the problem.
> 
> Docking should *not* work for components with csDesignTime - that means the LCL
> should prohibit it.

Right. Unfortunately I could not yet find the places for these checks, 
mouse dependent actions are hard to debug. There reside more bugs in the 
dock manager(s), I'll try to make an dock manager with emulator 
capabilities, just for debugging.

> Can you give some more details how to reproduce this bug?

You need two forms, a dockable one with DragMode=dmAutomatic (and some 
components on it), the other one [with a panel] with DockSite and 
UseDockManager = True. Then just selecting the dockable form with the 
mouse at design time, e.g. for setting properties, will start producing 
random frame rects wherever the mouse goes.

BTW, when I want to test my own dock manager, what exactly has to be 
done to install that manager? There seems to be one or more global 
variables that are used in the initialization of Controls.pp.

Please note that I want to have none of the existing dock managers by 
default, since I suspect some bugs just in their initialization. In my 
dock-test project I get an exception(?) almost all the time, when the 
program is started, with only an "Execution paused" and an hint "Some 
day an assembler window..." :-(


>>>> When I use the built-in FPDoc, how to publish the results?
>>> Do you mean, you want to see the fpdoc content without the IDE, for example
>>> as html or chm files?
>> I want others to see my updates, too.
> 
> I'm not sure what you mean. If you share the sources with others then they have
> the fpdoc xml files too and so they can see your changes.

Okay, I found out that I have to submit an patch. Which folder(s) should 
be diff'ed, in order to exclude changes not related to the documentation?


>>> they at least write a short sentence for each element. It is not meant as a
>>> real help editor. That's the purpose of lazde.
>> Then please make it compile, or provide at least a working binary.
> 
> Done in 17762.

You already fixed most of the bugs :-)

Only in lazde.lpr the line
   {$IFDEF WINDOWS}{$R manifest.rc}{$ENDIF}
causes an error "no resources...". (On Windows, of course ;-)

BTW, the same error message comes up when a new project is started 
before saving it. This situation could be checked in the IDE...

Thanks for your quick response :-)

DoDi




More information about the Lazarus mailing list