TForm Create problems

[mtanner]

Lots here for me to digest, thanks for all this.

I do understand the role of lfm files, and I never edit them, hardly ever look at them.

I have, as suggested, tried "Check LFM file in editor", and it seems ok, giving the message "Classes and properties exist. Values were not checked".

I hve been using a prpogram structire that creates files dynamically for some time with no problems. Forms are desighed in Desoigner, taken out of auto-create, form variable deleted. Then when the form is needed iut it created by Tabc.Create(Main).  The form may, at some other point in the app, get deleted.

 Note I have been using TabcForm.Create(Main) and not CreateForm. What is the difference, apart from syntax and first CreatreForm window becoming main form?

I have other forms, apart from the one giving this problem, that get created in exactly the same way (99% same actual code, obviously calling a different formclass.Create). These other forms behave the way I want, with no problems.

There was one thing I did regarding the LFM file for the problem form that may be relevant.  This is a big app, with many different forms. For each form there is the PAS and LFM files, plus some application PAS files concerned with application calculations, drawing a chart, and arranging controls on the form. I decided to put all the files for the problem form in a sub-folder. So I created a sub-folder, then moved (Windows Explorer) the files to the sub-folder. I then removed the files from the app (since the app would still be expecting them in the main folder) and added them (from the sub-folder) to the app. I cannot be sure if this exactly coincided with the appearance of the problem, but it was around that time. I have since reversed this to put all the files back in the main folder for the app. I would have thought that *.lfm in the forms PAS file would pick up the LFM as long as it was in the same folder, but maybe there is more to it?

I shall review all the advice so far, await repliesd regarding  CreateForm vs Create and sub-folders. Then my plan is to rebuild the problem form, under another name, copying across the controls. My thinking is that this will give me a "clean" LFM file.

[mtanner]

Just a snipped. Application.CreateForm(TabcForm,AbcForm); produces the same behavior as AbcForm:=TabcForm.Create(Main);

[mtanner]

Another snippet.

The forms are created in the OnClick methods for either TSpeedButtons or TMenuItems.

I don't think it's accurate to say I am guessing. I am comparing code that does not work with code that works. The first statement that is different between work/fail code is the Create being for different forms, and that is the statement in which the program hangs. There is also the evidence that the problem form used to work, and (in the famously unbelievable words of programmers everywhere) I do not think I've changed the code for the problem form.

I have tried putting a break-point on the Create, and yes it breaks there, but then I cannot display anything useful. Debugger is on. I admit to being ignorant about Lazarus debugging facilities. My experience is that I have very few problems with the "infrastructure" of forms and event handling. My apps are rather complicated scientific/engineering apps, very mathematical. They also tend to be highly iterative, so any debugger-like tracing typically produces tsunamis of breaks/data, because my bugs tend to be hundreds or thousands of iterations into the same (very long) loops of code for an optimisation or simulation algorithm, so I need to hand-craft debugging, usually with If ... ShowMessage.  Not elegant, but effective for me. So I am definitely an amateur when it comes to trying to get useful stuff out of breakpoints.

[mtanner]

To howardpc.

Your comments are very interesting. I would certainly agree that designing a form with the Designer and using LFM files is the best way, and I thought I was doing that. I've written a lot of stuff in Delphi, and I think only once did I (successfully) build a form from scratch via code, creating all the controls. Something to do only when there is a compelling reason, which is hardly ever in my experience. ( I thinbk it was to display warnings from within a DLL).

I've been using Form2:=TForm2.Create() for ages, with no problems. I am not even sure now why I started using this, and not Application.FormCreate Possibly I though that, if TForm2 is a "sub-form" to TForm1, making sense ony while TForm1 exists (and ShowModal not being appropriate), then by coding Form2:=TForm2.Create(Form1) then Form2 would get cleaned up automatically when Form1 was deleted. Otherwise Form2 might hang around until the application was terminated.

[FTurtle]

What is the difference, apart from syntax and first CreatreForm window becoming main form?

I don't see any pluses for use Application.CreateForm for coding by hands.
Minuses:

1. Owner is always Application. You may need assign as Owner some particular form.
2. Application.CreateForm call virtual constructor Create(AOwner: TComponent)
   You may need use other constructor.
3. Application.CreateForm may mask gross errors when using global variables.
   a) Global variables better to avoid as much as it possible.
   b) Better get error instantly instead long-long searching later.

and sub-folders.

Rule number one when begins some strange after copying, renaming, updating and etc.:
Run once Build instead Compile.

And always, before "some strange" will begin:
You should clean folders from any old copies of souces and compiled files before compile something. I dont know how in Lazarus, but in Delphi good practice was to close all files opened in editor.

Avoid situation when exist few files with same name in different directories.
Avoid existing of few copies of same directory at same time.
After renaming ensure that file with old name not exist.
 

[FTurtle]

Suggestion:
In line "ABC:=TabcForm.Create(Main);"
do Ctrl-Click on "TabcForm"
(or choose "Find declaration" in context menu).
Did you've jumped in right place?

[engkin]

I don't think it's accurate to say I am guessing.

If you are responding to my post, then there is a misunderstanding. I meant that is me guessing. 

[mtanner]

Still strggling withg this. IUt boils done to

TabcForm.Create(Main) fails (though not with all the various forms in my app)
TabcForm.CreateNew(Main) works

which suggest something to do with the lfm file, though I cannot find any problems with the lfm file.

Current straw at which I am grasping is that I have {$mode objfpc) in some modules though not all, so am currently going through making sure all modules have {$mode objfpc}.

I have also constructed a skeleton form with no controls, which creates ok. I plan to add controls to this skeleton to see what makes the create fail.

[mtanner]

I have some more definite information now.

For the skeleton form, with no controls, TabcFor..Ceate(Main) works ok.

Still works if OI add a TTabControl to the form.

When I add a TChart to the form, the Create fails.

So the problem is with TChart.

[mtanner]

And on checking the other forms in the app, it does appear that the ones which cause Create to fail have a TChart, and those without a TChart seem to Create ok.

On the other hand, another app with the same structure, forms with TCharts do Create ok.

Also I built a simple demo app, a main form and two secondary (not auto-create) forms. The main form has two buttons,which each crate one of the secondary forms. Bitg secondary forms Create ok. I put a TChartmnon one of the secondary forms, and it still both Create ok.

So it looks like I am doing something to my TCharts which prevents the containing forms being Create-d ok. And in one of may apps and not the other.

Again, any suggestions would be gratefully received.

[FTurtle]

Which OS and version of Lazarus do you use?

[mtanner]

From an earlier post:
I have to confess I'm still on XP - in process of moving everything to later Windows, but still using XP because I'm converting stuff from Delphi6/TeeChart for which I need XP. So I suppose that does raise the possibility of Lazarus/FPC being incompatible with XP, though it's working fine with a lot of other very similar code. And then why would the Create fail on some forms but not others? For the record I'm using Lazarus #1.6.4, FPC 3.0.2, SVN 54278.

Note that the problem app used to work ok. not sure what I've done to make it fail. And another similar app works ok. So I suspect it is some characteristic of the TCharts, or something about packages in use, maybe order of packages even.

[mtanner]

I am beginning to think this problem is about strings.

The unit TAChartAxisUtils has H+, so that in the declaration of TChartAxisMarkToTextEvent
         String means AnsiString

If I have a form unit with {$mode objfpc) and no H command then
         String means shortstring
and an OnMarkToText procedure declaration generated by the form designer will then be declared effectively with a shortstring parameter in which the user modified text will be returned. So presumably the TChart code will take this shortstring returned value and try and use it, effectively typecast it, into an ansistring. So an access error is unsurprising.

If this analysis is correct then the problem is not one of creating the form, it is becaus I have changed the mode statement. The lesson is, I suppose, allways use $H+ at the top of form units, and be aware that TChart parameters should be assumed to be ansostrings.

(I have allways used shortstrings in my apps. They are sufficient for my purposes, and don't give heap reference difficulties. Seems I no longer have that luxury of string simplicity.)