Delphi from Lazarus project descriptor lazarus / 10-Designer ---------------------------------------------------------------------- x2nie · 2014-05-19 09:14 Hi all ! In lazarus, there is a converter tool to run Delphi project inside Lazarus (via creating *.lpi), plus it is able to keep and share the same form file (*.dfm). Now, how to create a Delphi compatible project using Lazarus (oke) .. with plus related the delphi form file*.dfm (bug) ? ----------------- My trial when developing Project Descriptor is the project (*.dpr) + unit (*.pas) are well created, But It didn't create the delphi form (*.dfm), so no form shown after project descriptor called. Is it a bug or I did wrong configuration somehow? Regards, ---------------------------------------------------------------------- marcov · 2014-05-19 09:25 Afaik that is not prepared functionality.  Probably you need to ask Embarcadero to support import from Lazarus. At least they are then responsible for the version mismatch. P.s. renaming lfm's to dfms didn't work? ---------------------------------------------------------------------- x2nie · 2014-05-19 11:20 @marcov: thank you for response. It is not related to Embarcadero, It is exactly in Lazarus. But, maybe you misunderstand with my poor english. My apologize about it. I mean: * I create a Lazarus package * add a TProjectDescriptor class in unit +Register project type as *.DPR * add a TFileDescPascalUnitWithResource +Register resource unit as *.DFM * add above unit into that package * install package to Lazarus. After Lazarus restart, I call the descriptor (I've create above) with:Menu File --> New ...Delphi Application. see attachment. And, viola! A new Delphi project created. Quote from: x2nie on May 19, 2014, 11:14:39 amBut It didn't create the delphi form (*.dfm), so no form shown after project descriptor called. During answering your response, I am creating a new clean package and I am surprised that here is new form shown. So, the form creation issue was yet solved. Perhaps there was something misconfigured in my prior package, or maybe the issue has been solved in trunk. Anyway, I still could not run that new application with error: Quote unit1.pas(34) Error: Can't open resource file "D:\v\_bak\laz2d\output\unit1.dfm" unit1.pas(34) Fatal: There were 1 errors compiling module, stopping Quote from: marcov on May 19, 2014, 11:25:40 amP.s. renaming lfm's to dfms didn't work? Yes, after saving the entire application files, there were unit1.LFM. and after rename it to .DFM everything goes fine. So, here is still a bug that is Lazarus couldn't create correct name of Delphi form (shall *.dfm). ---------------------------------------------------------------------- x2nie · 2014-05-19 11:47 Quote from: x2nie on May 19, 2014, 01:20:49 pmSo, here is still a bug that is Lazarus couldn't create correct name of Delphi form (shall *.dfm). I've report it here: http://bugs.freepascal.org/view.php?id=26192 ---------------------------------------------------------------------- mattias · 2014-05-19 15:17 The bug tracker is the wrong place to discuss this issue. Let's discuss here in the forum. If the LCL writes a property, which the VCL does not know or which value is not understood, the form loading will stop with an error. You will notice this only by compiling it with Delphi, running the application and opening the form. How do you want to avoid this? ---------------------------------------------------------------------- x2nie · 2014-05-19 17:02 Quote from: mattias on May 19, 2014, 05:17:12 pmIf the LCL writes a property, which the VCL does not know or which value is not understood, the form loading will stop with an error. You will notice this only by compiling it with Delphi, running the application and opening the form. How do you want to avoid this? Thanks Mattias, Yes, in Delphi, even I often face that situation when opening from downgraded/upgraded Delphi versions. So, what I did is the same way when I load an edited form from Lazarus. On error when loading a form: This way: Generally the IDE (delphi/lazarus) tells in which file/form the error- loading occurred.If I am sure what is going on in that file/form, I usually click "Ignore" button and I lost some known properties.When am not sure what going on, or when I don't want to lost any TComponent's properties, I click "Cancel" and the form is remain hidden. Next, I open the form (*.dfm/lfm) using notepad / delphi as text editor, edit manually the part that I expect as error, and try again open the form (press F12).When error occurs again, I repeat step 2.On error when debugging form, This way: I stop debug (Ctrl+F2)I open all files/ all form withing the program: View Unit.. -> Select all --> oke.Error might then appear in much/few files.I resolve them per-file, with the steps in "When loading form" above.I repeat prior step, until I could open all units without error any longer. ---------------------------------------------------------------------- x2nie · 2014-05-19 17:32 Quote from: mattias on May 19, 2014, 05:17:12 pmHow do you want to avoid this? (I went to google translate, and I got better understanding about the question, somehow). I cant avoid that, & I don't want to avoid that, Mattias. The error is normal, even I think better to lost some component's properties than lost the entire project usability. Once we know that there was a potential error when using shared form- file (*.dfm), we can avoid runtime error by loading entire unit inside that program. Often, everything will be alright then. ---------------------------------------------------------------------- x2nie · 2014-05-20 09:40 Oh my God. It is not that easy as said to save .DFM by Lazarus. The content's format is fine, the content of generated .LFM is also perfectly usable. The only one mistake by lazarus is saving wrong file extension, that's all ! (It should be saved as .DFM, but the generated file in disk is always .LFM) --------------- So far, I found 3 classes that are (IMHO) overlaped when handling the resource-unit-file, they are: * TLFMUnitResourcefileFormat <-- TUnitResourcefileFormat. * TFileDescPascalUnitWithResource <-- TFileDescPascalUnit <-- TProjectFileDescriptor. * TUnitInfo <-- TLazProjectFile. I was spending teens hours, and still couldn't resolve it yet. But, I suspect that my big proble was here: //file:lfmUnitResource.pas line 86Code: [Select]class function TLFMUnitResourcefileFormat.GetUnitResourceFilename(   AUnitFilename: string; Loading: boolean): string; var   DFMFilename: String; begin   Result := ChangeFileExt(AUnitFilename,'.lfm');   if not FileExistsCached(Result)   // ToDo: search in source editor   then begin     DFMFilename:=ChangeFileExt(AUnitFilename,'.dfm');     if FileExistsCached(DFMFilename) then       Result:=DFMFilename;   end; end; the "todo" seem couldn't be done because the given filename (parameter) is seem as never created, therefore we couldn't use CodeBoss to get "source" file content, which is in that turn is required to FindResourceDirective. I guess the code above need more parameter to generate a better/correct result. -------- ---------------------------------------------------------------------- marcov · 2014-05-20 10:27 I wouldn't mind having a simple "keep form files .DFM" tick in the project and either.  I have a lot of simple apps that I use with both Delphi and Lazarus (think as GUIs for stuff as textfile/fileformat conversion or simple instrumentation with tcomport), and dealing with LFN is a chore for that. ---------------------------------------------------------------------- x2nie · 2014-05-20 10:55 Quote from: marcov on May 20, 2014, 12:27:50 pmI wouldn't mind having a simple "keep form files .DFM" tick in the project and either.  Do you expect: there is a checkbox in Project Option ? No, Marcov ! it will never required. Each unit (.pas / .pp)'s resource will be automatically detected: whether .LFM, .DFM, .XML via resourceDirective {$R *.DFM}. Current Lazarus already supports them perfectly. My problem is limited to: the first saving that form file, when the form is generated by File > New.. dialog. So, don't worry about about LFM/DFM maintainability. It was here already. ---------------------------------------------------------------------- marcov · 2014-05-20 11:20 Quote from: x2nie on May 20, 2014, 12:55:25 pm So, don't worry about about LFM/DFM maintainability. It was here already. Maybe I should use the conversion tool then to import them :-)_ ---------------------------------------------------------------------- x2nie · 2014-05-20 11:55 Quote from: marcov on May 20, 2014, 01:20:11 pmQuote from: x2nie on May 20, 2014, 12:55:25 pm So, don't worry about about LFM/DFM maintainability. It was here already. Maybe I should use the conversion tool then to import them :-)_ Now I am worry that I misunderstand your words. I really couldn't guess why you should use conversion tool? to import what from what inside what? (from delphi to open using lazarus? What is you are expecting for DFM/LFM ? Are you have problem using DFM in Delphi after edited in Lazarus? Please, if there any trouble related to DFM~LFM, share your experience here. ---------------------------------------------------------------------- x2nie · 2014-05-20 14:30 Okay Martin, JuhaManninen, Marcov... I ended up with a patch. see bugtracker linke above. My patch will also integrate & simplify of creating new TFileDescPascalUnitWithResource process. tested using xmlresource.lpk in lazarus example directory. I hope you like it.