I've got a form which I'm creating manually before a program's main form, in order to read configuration settings which are needed early. The form contains a notebook, and I've implemented forward/backward buttons to give a wizard-like interface. It's also got a modal cancel button to prevent the app from starting. That combination's working fine.

I've moved the notebook and its contents into a frame, made sure that the events are hooked up, and dropped the frame onto a clean form.

When the program runs, the form is created and displayed and the modal cancel button works, but none of the other events fire in response to user actions. This is with Lazarus trunk + 2.6.0.

I've just written a trivial program with a frame and button on the main form and events appear OK, so it appears to be something to do with early-creation of the form and content. Unless anybody can point out what stupid mistake I'm making I'll extend my test program with an early-created form and raise a bug if the problem persists.

It should work.

Can you create a small example to demonstrate the problem?

Mattias

I can't duplicate it with a newly-created test program. However I notice that this program has implementation ... {$R *.lfm} in (at least) those units with forms, while the program giving the problem doesn't. Any thoughts would be appreciated before I wade in trying to "fix" things.

Is the OnClick event of the button assigned at runtime?

Mattias

No. At frame design time, and then the frame is placed on the form (I've previously been caught by frame updates not propagating to frames which are already on forms) and set to client alignment. Save and build.

Event handlers are installed from the LFM file. If you don't have one, or don't $Read it, no handlers will be hooked in during creation. Also all other properties will have default values, then.

DoDi

Hans-Peter Diettrich hat am 31. Januar 2013 um 11:45 geschrieben:

TFrame raises an exception if no resource was found.

Probably the program uses the old .lrs files {$i frameunit.lrs}

Mattias

Yes, found 'em. What should I be doing for new versions of Lazarus: removing the $i and inserting $r? If so is there a conditional that will allow me to automate it depending on version?

Mark Morgan Lloyd hat am 31. Januar 2013 um
12:39 geschrieben:

If you need to support very old Lazarus versions, then keep using lrs files. The $R resources are just nicer and need less memory. You can even mix lrs and $R resources in programs. This has nothing to do with your bug. That means: unless you silently catch the TFrame exception.

Mattias

Mark Morgan Lloyd hat am 31. Januar 2013 um
11:38 geschrieben:

Set a breakpoint in TCustomFrame.Create and single step to see what is executed.

Mattias

I'm still trying to look at this, but a side question if I may. Could this be caused by the fact that one of the directories is accessed via a symlink? I notice that the IDE doesn't much like this, with extra tabbed panes being opened whenever there's a compilation error and the risk of "file changed on disk" inconsistencies if I don't force a manual save.

Symlinked files are a problem. Symlinked directories are only a problem, if you use both paths in the same project.

Mattias

I've never tried that.

Symlinked directories are only a problem, if you use both paths in the same project.

I'm definitely not doing that, and they're definitely a problem. I've got a tree like

/usr/local/src/inifiles
/usr/local/src/inifiles/trunk

/usr/local/src/heavywethers
/usr/local/src/heavywethers/trunk
/usr/local/src/heavywethers/inifiles -> /usr/local/src/inifiles

with the project only referring to ../inifiles/trunk:

<SearchPaths>
<IncludeFiles Value="$(ProjOutDir);$(LazarusDir)\ide"/> <OtherUnitFiles Value="..\inifiles\trunk"/>
</SearchPaths>

The relative path "../inifiles/trunk" is passed absolute to the compiler. If for example your project directory
is /usr/local/src/heavywethers/trunk the IDE passes -Fu/usr/local/src/heavywethers/inifiles/trunk
to the compiler.

Mattias

Which presumably means that if there's an error the compiler reports the absolute path, and the IDE doesn't realise that it's already got that file open.

1. Why should the compiler report a wrong path?
2. The files' inode may be the same, but for all other purposes they are two different files.

Mattias

That's not quite what I said. You pointed out that the IDE was converting the relative path to an absolute one which is what the compiler sees, the compiler reports an absolute path in any error message, and by the time it sees that the IDE's forgotten that it's already got the file open.

2. The files' inode may be the same, but for all other purposes they are two different files.

In the case of a symlink- arguable. But I think the case you've pointed out is purely to do with the absolute/relative path to a file, and in that case it's definitely the same file.

Sorry. You lost me.

For all searches the IDE must handle them as two different files, because of the concept of relative (search-) paths.

Mattias

Well, I obviously accept that I'm Doing It Wrong, and that having symlinked directories in the search path is ill-advised (which to my mind is unfortunate). I honestly don't want to bang on about this to the extent that I appear boorish, but I'll try once more in the interest of highlighting something which I think is a problem.

The project file is /usr/local/src/heavywethers/trunk/heavywethers.lpi and the program file is in the same directory. One of the files it's referencing is dbconfig2.pas (internal name DbConfigCode2), which is in the absolute directory /usr/local/src/inifiles/trunk accessed via a symlinked directory and the project's "Other unit files" setting as ./inifiles/trunk.

If I force an error into this file and force all files to be saved, when I run the compilation I see

[TCompiler.Compile] CmdLine="/usr/local/bin/ppc386-2.6.0 -MObjFPC -Scagi -O1 -g -gl -vewnhi -Se3 -Fi/usr/local/share/lazarus-trunk/ide -Fl/opt/gnome/lib -Fu/usr/local/src/heavywethers/inifiles/trunk ..
Compiling HeavyWethers.lpr
Compiling /usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas

but I now have two tabbed panes in my source editor: "DbConfigCode2" and "DbConfigCode2(2)" with the latter focussed. If I fix the error on the focussed pane, force save-all, and hit compile I get an immediate dialogue "Some files have changed on disk:"
"/usr/local/src/inifiles/trunk/dbconfigcode2.pas". I can fix that by selecting "Reload from disk" *provided* that I've done manual saves after every change, If I don't force the saves then the most recent edits might be lost.

The second tabbed pane should not, to my mind, be opened: the file already exists on the screen, and the only reason that the IDE thinks it's not is that it's not kept track of the fact that it's canonicalised the path when it passed it to the compiler. Also the dialogue should not pop up: all changes have already been flushed to disk but the IDE hasn't adequately realised that.

Many people use symlinked directories without problems.

I guess you mean "../inifiles/trunk", which resolves to "/usr/local/src/heavywethers/inifiles/trunk/".

To avoid misunderstanding: When I'm talking about "absolute filename" I meant everything that starts with a /. No matter if a part contains a symlink or mount point.

The project (i.e. IDE and compiler)
uses /usr/local/src/heavywethers/inifiles/trunk/dbconfig2.pas.

Good.

but I now have two tabbed panes in my source editor: "DbConfigCode2" and "DbConfigCode2(2)" with the latter focussed.

And that's where you loose me.
Why should /usr/local/src/inifiles/trunk/dbconfigcode2.pas be open in the editor? From the project's point of view it is an unrelated file.

Well, with some work it is possible to find out if two symlinked files are the same under Unix and improve the messages. It is not possible in general to find duplicates. For example with network shares or special file systems.

It must pop up the file given by the compiler. That is the one in the project and is therefore parsed with the project settings, the other is not. The two files share only sectors on the disk.

As I wrote:
You can use linked directories, but within a project you can use only one of them.

Mattias

You tell me! But the IDE opens a new tab/pane, and that's the whole point I'm trying to make!

As I wrote: You can use linked directories, but within a project you can use only one of them.

I'm trying to, dagnabbit! :-)

Sorry.
The IDE does not resolve symlinks in paths. That means if the IDE opens a wrong file, then it does so, even if the two directories were copies instead of symlinks. Your talk about a problem with symlinks mislead me.

So, let's forget the symlinks and find out why the IDE opens the wrong file.

Please confirm:
The messages window shows an error on the file
/usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas but the source editor opens the file
/usr/local/src/inifiles/trunk/dbconfigcode2.pas
Right?

Don't worry, it was some while before I started focusing on what the real problem was.

To add context for the error message, the error I've forced in looks like

-----8<-----
type TDbConfigInit= procedure(confFrame: TDbConfigFrame; init: boolean= true);
TDbConfigRead= function(confFrame: TDbConfigFrame; mr: TModalResult): boolean;

ty pe // Line 22

{ TDbConfigFrame }

TDbConfigFrame = class(TFrame)
----->8-----

/usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas(22,4) Fatal: Syntax error, "=" expected but "identifier PE" found

but the source editor opens the file /usr/local/src/inifiles/trunk/dbconfigcode2.pas Right?

I think so, or at the very least it opens a new tab/pane so that I've now got tabs labeled "DbConfigCode2" and "DbConfigCode2(2)". "Information about the IDE" tells me

Project.SomethingModified Session

Project units:
./../inifiles/trunk/dbconfigcode2.pas SessionModified Project units:
./../inifiles/trunk/dbconfigcode.pas SessionModified

which based on the project directory being
/usr/local/src/heavywethers/trunk implies
/usr/local/src/inifiles/trunk/dbconfigcode2.pas (I'm trying to be cautious jumping to conclusions here).

Source -> Unit Information -> General on the new DbConfigCode2(2) tab tells me /usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas [manual transcript] which is what the file should be. ... Unit paths refers to /usr/local/src/heavywethers/inifiles/trunk which is OK. Source paths ditto.

But Source -> Unit Information -> General on the original DbConfigCode2 tab tells me it's /usr/local/src/inifiles/trunk/dbconfigcode2.pas which is wrong.

I need to be very cautious about jumping to any conclusions over this (having already been wrong once), but it looks as though the compiler is getting and reporting the right path

Compiling /usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas

but the IDE at some earlier stage has resolved it to /usr/local/src/inifiles/trunk/dbconfigcode2.pas which it shouldn't. That actually fits my experience that given that sort of duplicate tab it's safer to close the older one.

If I close the older tab/pane, save-all and terminate then restart, the one tab that's displayed relating to that file has the correct name /usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas.

I think it's worth noting that since I updated this copy of the IDE etc. to trunk (i.e. rather than it being a couple of weeks old) I'm seeing additional startup warnings

FindMissingClass DbConfigFrame1:TDbConfigFrame IsInherited=False TLazSourceFileManager.LoadLFM loading nested class TDbConfigFrame needed by /usr/local/src/inifiles/trunk/dbconfigcode.pas

However I think that's something to do with the non-working OnClick which I'll get back to presently, this business with tab/pane duplication is at least a few weeks old.

Is this "../../" or really "./../" ?

see above.

Source -> Unit Information -> General on the new DbConfigCode2(2) tab tells me /usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas [manual transcript] which is what the file should be.

ok

... Unit paths refers to /usr/local/src/heavywethers/inifiles/trunk which is OK. Source paths ditto.

ok

But Source -> Unit Information -> General on the original DbConfigCode2 tab tells me it's /usr/local/src/inifiles/trunk/dbconfigcode2.pas which is wrong.

What is this "original"? When is it opened?
In my former mails I assumed you had opened it yourself.

yes.

but the IDE at some earlier stage has resolved it to /usr/local/src/inifiles/trunk/dbconfigcode2.pas which it shouldn't.

What is this "some earlier stage"?

All tabs are named uniquely. If you open two units with the same name one will get the "(2)" appended. The "(2)" vanishes when the name becomes unique again.

It simply means: This form is opened and needs some frame of another unit.

However I think that's something to do with the non-working OnClick which I'll get back to presently, this business with tab/pane duplication is at least a few weeks old.

Mattias

I'm pretty sure that was ../../ but the cut or paste operation was trimming it. However I think we've got a Heisenbug here: "Information about the IDE" -> Modified is now displaying

SourceEditorManager.SomethingModified

Source Editor:
/usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas Component=True

and the IDE now doesn't open a duplicate tab/pane when the compiler complains about the error. I think what's happened is that my action of restarting the IDE with the file closed has sorted things out. In other words this lot is still approximately valid...

dbconfigcode2 is the name on the tab created when the IDE (at startup) read the project. I was assuming that dbconfigcode2(2) was the one that the IDE created when the compiler reported the error, but looking at the file paths I'm not entirely sure.

When the IDE was opening the project.

..up to this point where I've just done something that makes the problem go away.

All tabs are named uniquely. If you open two units with the same name one will get the "(2)" appended. The "(2)" vanishes when the name becomes unique again.

Yes, but which tab gets the suffix: the one that already exists or the newly-created duplicate?

So it looks as though it's something to do with the saved state of the project, i.e. which files are listed as to be opened when the project is loaded. The file giving the problem had been open (across multiple sessions of the IDE) ever since the unit and associated frame was created and saved, I can't remember exactly how I did the save (i.e. whether it was an explicit save-all or an implicit save when the compiler was run or the IDE shut down).

If the compilation is run and finds an error where the file isn't already open, the file is opened with the correct path and there are no further problems.

Drat- it's just started happening again. The thing that appears to have made the difference was telling the IDE to open the frame associated with the unit, I can now see both forms of the path/name stored in the .lps file:

<Unit12>
<Filename Value="../../inifiles/trunk/dbconfigcode2.pas"/> <IsPartOfProject Value="True"/>
<ComponentName Value="DbConfigFrame"/>
..
<Unit15>
<Filename Value="../inifiles/trunk/dbconfigcode2.pas"/> <ComponentName Value="DbConfigFrame"/>

Reading the project simply restores the files last time open. That does not count. Question still open: When was the wrong file opened?

See above.

When a second is opened it gets the (2), the third gets (3), and so forth. It does not matter which one is the project's one.

The does not matter for the session.

If the compilation is run and finds an error where the file isn't already open, the file is opened with the correct path and there are no further problems.

Nice.

You can see that the IDE knows that Unit12 belongs to the project, while Unit15 is simply a file on your disk.

About "the IDE to open the frame associated with the unit". Which file is "the frame" and which file is "the unit"?

Mattias

It would appear either at the time the unit is first saved, or when a frame (possibly form) is opened that crosses an ambiguity.

Which fits in with the original tab (DbConfigCode2) being given the wrong filename by the IDE, and the new tab (DbConfigCode2(2)) getting the right filename from the compiler's error message.

That's what I thought- for a while at least :-)

If I delete the .lps file and start the IDE it seems to open dbconfig2.pas by default, I find this in .lpi:

<Unit12>
<Filename Value="..\..\inifiles\trunk\dbconfigcode2.pas"/> <IsPartOfProject Value="True"/>
<ComponentName Value="DbConfigFrame"/>
<HasResources Value="True"/>
<ResourceBaseClass Value="Frame"/>
<UnitName Value="DbConfigCode2"/>
</Unit12>

If I run the compilation (knowing there's an error in that file) and save-all (even without correcting it), I have DbConfigCode2 and DbConfigCode2(2) tabs and the new .lps includes

<Unit12>
<Filename Value="../../inifiles/trunk/dbconfigcode2.pas"/> <IsPartOfProject Value="True"/>
<ComponentName Value="DbConfigFrame"/>
<HasResources Value="True"/>
<ResourceBaseClass Value="Frame"/>
<UnitName Value="DbConfigCode2"/>
<EditorIndex Value="0"/>
<WindowIndex Value="0"/>
<TopLine Value="1"/>
<CursorPos X="1" Y="1"/>
<UsageCount Value="20"/>
<Loaded Value="True"/>
<LoadedDesigner Value="True"/>
</Unit12>
<Unit13>
<Filename Value="../inifiles/trunk/dbconfigcode2.pas"/> <UnitName Value="DbConfigCode2"/>
<IsVisibleTab Value="True"/>
<EditorIndex Value="1"/>
<WindowIndex Value="0"/>
<TopLine Value="3"/>
<CursorPos X="4" Y="22"/>
<UsageCount Value="10"/>
<Loaded Value="True"/>
</Unit13>
</Units>
<General>
<ActiveWindowIndexAtStart Value="0"/>
</General>
<JumpHistory Count="1" HistoryIndex="0">
<Position1>
<Filename Value="../inifiles/trunk/dbconfigcode2.pas"/> <Caret Line="1" Column="1" TopLine="1"/>
</Position1>
</JumpHistory>

I think the answer is that unit12 is the frame and unit13 is the form.

Looking at the IDE Source -> Unit Information, the tab DbConfigCode2 is /usr/local/src/inifiles/trunk/dbconfigcode2.pas and the tab DbConfigCode2(2) is
/usr/local/src/heavywethers/inifiles/trunk/dbconfigcode2.pas (both of those manually transcribed).

Hope that's what you were asking :-)

Going back to this, r40191 shows me that event handlers were not being saved in the frame (OnClick event etc.) but reselecting those seems to have fixed it. So there might have been an issue in some revisions of trunk.

One thing that I'm now getting (at least up to r40200) is that when the IDE reads a form containing a frame I get a dialog telling me the .lfm can't be found:

Unable to find the component class "TDbConfigFrame". It is not registered via RegisterClass and no lfm was found. It is needed by unit:
/usr/local/src/inifiles/trunk/dbconfigcode.pas

However aborting/cancelling the load appears to have the effect of making the load complete, the project is intact and compilable. This doesn't appear to be related to my use of a symlink.

What form, what frame?

Unable to find the component class "TDbConfigFrame". It is not registered via RegisterClass and no lfm was found. It is needed by unit: /usr/local/src/inifiles/trunk/dbconfigcode.pas

Is this correct:
Project directory is
/usr/local/src/heavywethers/trunk
Unitpath is "../inifiles/trunk"
So these files belong to the project:
/usr/local/src/heavywethers/inifiles/trunk/*.pas
These can *not* be found by the project:
/usr/local/src/inifiles/trunk/*.pas

Now you are asking about the non-project unit:
/usr/local/src/inifiles/trunk/dbconfigcode.pas

Where is TDbConfigFrame defined?

However aborting/cancelling the load appears to have the effect of making the load complete, the project is intact and compilable. This doesn't appear to be related to my use of a symlink.

Mattias

Correct.

No, dbconfigcode.pas and dbconfigcode2.pas are both explicitly in the project. As are a number of other units in ../inifiles/trunk.

Where is TDbConfigFrame defined?

In dbconfigcode2.pas. And the form onto which it's placed is in dbconfigcode.pas.

Huh?
"../inifiles/trunk" is "/usr/local/src/heavywethers/inifiles/trunk".

The folder "/usr/local/src/inifiles/trunk" is not in the unit path.

> Where is TDbConfigFrame defined? In dbconfigcode2.pas. And the form onto which it's placed is in dbconfigcode.pas.

Mattias

Somebody else has just reported this as
http://bugs.freepascal.org/view.php?id=23847 including an example project.

Is the folder in the unit path?

That example works here.
If you can reproduce the bug please give some hints.

Mattias

I'll check it later and append to the bug report. I think I've made enough noise on that one here, particularly since some of the problems I've been wittering about have been related to my questionable use of symlinks.