TEdit not editable

[geraldholdsworth]

This is a weird one - my project, imported from Delphi, has two forms (one is just an About dialogue box). On the main form, it has three TEdit controls. None of these allow anything to be entered. I could not find anything in the properties which might prevent this, and I have nothing in code to disable them.

But, just in case I'd missed something, I created a fresh TEdit control and changed no properties (apart from the size). This also is uneditable.

[howardpc]

If you want replies that are not random guesses you need to provide compilable code that shows the problem.

[geraldholdsworth]

I have no code to show relating to this issue. It is a TEdit on a TPanel on a TForm.
I then create a TEdit and place it directly on the TForm, no other parents.
Neither can be edited, and no parameters have been changed. They are Enabled, Visible, and not ReadOnly.

I can tell you that this is version 2.0.10 on Mac OS X 10.13.6.

[geraldholdsworth]

I have now got it working...and also got hints working (that's in another thread that someone started).
I changed one of the project options - Application page, ticked 'Use manifest resource', under Windows and changed the DPI awareness to on (True). I also filled out the Name and Description and ticked the UI Access box.

[jamie]

sometimes using the coverting tools things do not always go off well without a hitch..

its possible the original DFM file is still in the project path and laz is seeing that too..

A ReadOnly property maybe set in the DFM/LFM file that isn't getting named property that matches your names in the OI and thus
a background TEDIT maybe getting created, not the one you expect.

[geraldholdsworth]

sometimes using the coverting tools things do not always go off well without a hitch..

its possible the original DFM file is still in the project path and laz is seeing that too..

I've spent most of today removing all traces of Delphi from this particular project. I did a Publish Project then deleted all files that were not in the archive produced.
But, I have managed to solve this particular issue, and a couple of others, and am now, finally, getting the hang of Lazarus.

[winni]

Hi!

I have a rude and dangerous solution.

But before that you should have a look in the [MainUnit].lfm.
Perhaps you find some strange values or corrupted things.
Make a backup before you edit!

The rude solution:

First make a backup of your whole directory.
Add a new Form to your project.
Put exact the same components from your mainform on the [NewForm]
Do not insert more code into your new form.
Save it. And leave Lazarus.

Rename your [Mainform].lfm to [Mainform].lfm.old . Maybe you need it again.

Copy your [NewForm].lfm to [Mainform].lfm

Start  Lazarus again.
If you are lucky you get a running application.
With a uselesse [NewForm].
Then delete on the IDE Level the [NewForm].

If a corrupted lfm was not the problem: You got your backup.
As I told you before.

Winni

[geraldholdsworth]

Put exact the same components from your mainform on the [NewForm]

The thought had crossed my mind, but I got it fixed so no need - it was a settings issue (see above).

[Bart]

- it was a settings issue (see above).

Me curious: what setting caused this strange behaviour?

Bart

[geraldholdsworth]

Me curious: what setting caused this strange behaviour?

It was, in Project Settings, on the Application page, ticked 'Use manifest resource', under Windows and changed the DPI awareness to on (True). I found it odd because I was compiling on a Mac. I also ticked the UI Access box, but had to untick this later on to get it to compile on Windows.

[lucamar]

Have you tried to revert those changes to see whether it keeps working? AFAIK they have absolutely nothing to do with Mac but maybe setting them forced a rescan (or something like that) of all options and set them aright.

[wp]

This is a weird one - my project, imported from Delphi, has two forms (one is just an About dialogue box). On the main form, it has three TEdit controls. None of these allow anything to be entered.

This looks like a simple project. Would you mind to post the original Delphi project here so that I can try myself to port it to macOS? (Pack .pas, .dfm, .dpr and .dproj files into a common zip which you can upload under "Attachments and other options"). If you cannot publish it upload it to some cloud server and send me the link by PM. I think it is strange that changing a Windows-only project setting fixes an issue with macOS.

[geraldholdsworth]

This looks like a simple project. Would you mind to post the original Delphi project here so that I can try myself to port it to macOS? (Pack .pas, .dfm, .dpr and .dproj files into a common zip which you can upload under "Attachments and other options"). If you cannot publish it upload it to some cloud server and send me the link by PM. I think it is strange that changing a Windows-only project setting fixes an issue with macOS.

It's actually on my website. I've also published the converted (and now ongoing) Lazarus project on GitHub. So do please, go ahead and see what you can figure out.

[wp]

These are my steps converting your Delphi project to cross-platform Lazarus. I am beginning on Windows because I can have a look at the project in Delphi here. I am doing the conversion manually because I have more control over what is happening this way.

• Downloaded the sources. Loaded the project into Delphi XE 10.3 and verified that the project is compiling and runing without error. Unfortunately I do not have any data files and thus cannot test the project logically.
• Copied the .pas, .dfm and .dpr files to a separate folder for Lazarus conversion.
• Opened one of the dfm files to check that it is in text format (not binary). Here, all files are in text format; if they were not they could be converted by Lazarus (meu "Tools" > "Delphi conversion" > "Convert binary DFM to Lazarus LFM"
• Renamed the .dfm files to .lfm, and the .dpr file to .lpr. Lazarus could also work with the dfm files (I don't know about dpr), but renaming gives better flexibility because then it would be easier to make the project still compile with Delphi.
• Opened the pas files in Notepad++ and replaced the line '{$R *.dfm}" by {$R *.lfm}"
• Edited each pas file in Notepad++ and removed the namespace from the unitnames in the uses clauses (i.e. WinApi.Windows --> Windows, etc. }
• Loaded the .lpr file (former .dpr) into Notepad++, removed the namespaces from the unit names. Added "interfaces" as first unit.
• Tried to load the .lpr file into Lazarus. --> Message "Program detected..." --> Confirmed to create a new Lazarus project ("Yes" --> project type "Application").
• Trying to compile --> Error in unit "DiscImage": "cannot find System.Classes". Aaah: I forgot to remove the namespace here. So: System.classes --> classes, Vcl.ComCtrls --> ComCtrls, etc;
• Next compilation attempt: "Duplicate identifier "Disc"" in unit DiscImage. OK, there is a property Disc with the same name as this local variable; mode ObjFPC does not accept this. To fix this and all other issues of this kind I opened the project options > "Compiler options" > "Parsing" and selected "Delphi (-MDelphi)" in the "Syntax mode" combo box.
• Next compilation attempt: "Cannot find ImageList used by MainUnit". OK: the Lazarus image list is in unit ComCtrls, a unit ImageList does not exit --> comment its usage in the uses clause and make sure that ComCtrls is already listed.
• Next compilation attemp: "Cannot find pngImage used by MainUnit". Again: there is not LCL pngImage unit, its functionality is contained in unit Graphics --> comment "pngimage"
• Next: "Cannot find IOUtils used by MainUnit": Hmmm, I don't know what this is. Comment the unit to be able to continue. Let's see what happens...
• Then: "PopupMenu" not found: This is in the LCL unit Menus which is not listed. --> Add "menus" to the uses clauses.
• next: "Identifier not found "TDirectory"", in line TDirectory.CreateDirectory(path+windowsfilename)... I don't know of a class TDirectory in Lazarus, maybe a consequence of the removed IOUtils unit. I decided to use the plain old CreateDir and replace TDirectoryCreateDirectory(..) by it - this probably will work.
• At some time in this sequence I tried to access the lfm file by pressing F12. This failed because Delphi-typical properties like "BevelEdges" are not known by the LCL. The correct answer to the Read Error message box is "Continue loading". Sometimes you are prompted to accept removal of unknown properties which must be confirmed. But it did not happen here.
• Now the project compiles. However, the project still uses the Windows unit and thus is not yet cross-platform.
• Removed the unit Windows from all units (in MainFrom and About Unit).  I'm lucky: the project still compiles. Otherwise "Windows" would have to be replaced by LCLIntf.
• Another windows-specific unit is "Messages" - I remove it on a first try, lucky again! Normally I would have to add "LMessages" instead of "Messages"
• Another often used, non cross-platform unit is "Types" which must be replaced by "LCLType". This is not used here.
• Almost done. Let's clean up the unit list: Delphi usually adds the unit Variants which is barely needed.
• The program still compiles and runs on Windows. As noted I do not have data files and cannot test it logically...
• I copied the project to my dropbox which is connected to a VM with macOS Mojave.
• Opened the VM with macOS and copied the files from dropbox into my project folder. Loaded into Lazarus, compiled successfully. Runs, now on macOS (this moment is always exciting!).
• The three edit boxes are not read-only, even after unchecking the "LCLScaling" and "Use manifest" checkboxes. So, I don't know what you did wrong...

[geraldholdsworth]

These are my steps converting your Delphi project to cross-platform Lazarus. I am beginning on Windows because I can have a look at the project in Delphi here. I am doing the conversion manually because I have more control over what is happening this way.

Wow...you did a lot. Presumably this is what Lazarus does when it converts a project.

• Edited each pas file in Notepad++ and removed the namespace from the unitnames in the uses clauses (i.e. WinApi.Windows --> Windows, etc. }

I've done that bit too...Lazarus had commented out all those units, so I uncommented and removed the namespaces, then removed the duplicates. I think I also removed the Windows unit.

• Next compilation attempt: "Duplicate identifier "Disc"" in unit DiscImage. OK, there is a property Disc with the same name as this local variable; mode ObjFPC does not accept this. To fix this and all other issues of this kind I opened the project options > "Compiler options" > "Parsing" and selected "Delphi (-MDelphi)" in the "Syntax mode" combo box.

In my process to migrate it away from being MDelphi, I found the same error. Initially I changed the identifier name to "Disk", before I realised I had been stupid originally and could have just used "Result", and remove the identifier declaration completely.

• next: "Identifier not found "TDirectory"", in line TDirectory.CreateDirectory(path+windowsfilename)... I don't know of a class TDirectory in Lazarus, maybe a consequence of the removed IOUtils unit. I decided to use the plain old CreateDir and replace TDirectoryCreateDirectory(..) by it - this probably will work.

TDirectory is defined in the DiscImage unit. It is my own definition.

• The three edit boxes are not read-only, even after unchecking the "LCLScaling" and "Use manifest" checkboxes. So, I don't know what you did wrong...

I don't know either. It's an odd one. But thank you for doing all that. I've learnt a lot from that - thank you.
I'll go back over my code, because I'm sure there are still some of those units in it that you have removed.

Another oddity (and I know this is going off topic) I've found is with the function:
function TMainForm.IntToStrComma(size: Int64): String;
begin
 Result:=Format('%.0n',[Real(size)]);
end;

With {$MODE MDelphi} it returns 0, no matter what 'size' is set to (bearing in mind this works on Delphi). But change to {$MODE objFPC} and it works fine - returns a number (as a string) with thousands separators.