Show quoted text 7 lines
> 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.
Show quoted text 7 lines
>> 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..." :-(
Show quoted text 7 lines
>>> 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?
Show quoted text 5 lines
>> 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
