Hi

I have been converting EssModel Delphi program, partly as an exercise and partly because it could develop into a useful program or component. It is a reverse engineering class diagram tool.

I am facing more problems than expected. This is not related to Delphi converter in Lazarus but to the manual editing after it.

First, the code uses a trick. It typecast controls like TForm to a local TCrackControl just to reach the protected TControl.OnMouseDown and such.

  type
    TCrackControl = class(TControl);  // <-- empty local class
  var
    found: TControl;
    cc: TCrackControl;
and later:
  // 'found' can be TForm or anything.
  cc:=TCrackControl(found);  // <-- error
  cc.OnMouseDown := ...

It gives 'RunError(219)', and the whole Lazarus may become unstable. The typecast is actually OK because the controls inherit from TControl and OnMouseDown is defined there. According to Mattias this system is even used in Lazarus itself. In a small test project the same system worked for me, too. ???

The program used interfaces heavily, actually in a clever way. I thought they cause the above problem and changed the code quite much to get rid of interfaces. No difference, it still doesn't work.

Next problem: I noticed there are TActions defined in a DataModule which is created in MainForm.OnActivate handler, and the actions are used in form's menu and button. I thought it causes problems and I copied everything from DataModule to MainForm. I set the actions carefully like they were before and now menu items work but open-button does not. The exact same action is triggered by menuitem but not by button!
So, this refactoring didn't solve any problems but created a new one.

And then: before the program closes it writes recent files to registry. It gives an error when writing a string, although I can find the "reg.xml" file it wrote. The same thing works in my small test project without errors.

All the program's behavior is defined in project file, pascal source code and form files. Am I correct?
So, WHAT CAN CAUSE SUCH PROBLEMS? I have used many many hours already trying to solve this.
The program itself is not very important now, I could as well forget it. I just feel uncomfortable when there are errors which I can't explain. Besides I am supposed to improve Delphi converter but now I am not even able to convert a program myself...

My tests happened on Linux, with GTK2 and QT. If someone likes to look at the code, please do this:

  $ git clone git://github.com/JuhaManninen/Pascal.git

It is not big.
At least it should be easy to verify the MainForm.OpenButton doesn't work while it should, even though the program hasn't done anything yet.

Regards,
Juha

Zitat von Juha Manninen :

Do you mean the IDE becomes unstable because of a RunError in a debugged program?

RunError are critical. There is something very wrong in the code (e.g. dangling poniter, unintialized variable, etc). Please compile with all checks.

Just to make this clear:
I discourage such dirty tricks. It is better to fix the used class.

Can you create a small example to reproduce the problem?

Yes.
Although the lpi and lpk files are only needed for the compiler parameters.

So, WHAT CAN CAUSE SUCH PROBLEMS? I have used many many hours already trying to solve this.

Maybe the program worked only by accident.

A lot of files use windows codepages. Maybe the converter could try to fix that automatically?

At least it should be easy to verify the MainForm.OpenButton doesn't work while it should, even though the program hasn't done anything yet.

Mattias

Did you notice that there are two OpenButton? One has the action, the other not.

Mattias

Hi Juha,

I compiled ess-model from your git repo on win32.
Had to add 3 TODO's to make it compilable for win32.

Tried to commit the changes to your git-repo.
It was the first time I used git and it looks like my user-settings were not very good. The name used to commit was "master". I have changed my settings so next time it should be better.

That's it for the moment. Will play around with the sources as soon as I have some spare time.

Thank you very much for your incredible work you did for the DelphiToLazarus Convertion stuff !!!!

Regards,

Sam

--- Juha Manninen schrieb am Mo, 3.5.2010:

Von: Juha Manninen
Betreff: [Lazarus] Challenge of converting a Delphi project An:
Datum: Montag, 3. Mai, 2010 13:52 Uhr

Hi

I have been converting EssModel Delphi program, partly as an exercise and partly because it could develop into a useful program or component. It is a reverse engineering class diagram tool.

I am facing more problems than expected. This is not related to Delphi converter in Lazarus but to the manual editing after it.

First, the code uses a trick. It typecast controls like TForm to a local TCrackControl just to reach the protected TControl.OnMouseDown and such.

? type
? ? TCrackControl = class(TControl);? // <-- empty local class ? var
? ? found: TControl;
? ? cc: TCrackControl;

and later:
? // 'found' can be TForm or anything.
? cc:=TCrackControl(found);? // <-- error
? cc.OnMouseDown := ...

It gives 'RunError(219)', and the whole Lazarus may become unstable. The typecast is actually OK because the controls inherit from TControl and OnMouseDown is defined there. According to Mattias this system is even used in Lazarus itself. In a small test project the same system worked for me, too. ???

The program used interfaces heavily, actually in a clever way. I thought they cause the above problem and changed the code quite much to get rid of interfaces. No difference, it still doesn't work.

Next problem: I noticed there are TActions defined in a DataModule which is created in MainForm.OnActivate handler, and the actions are used in form's menu and button. I thought it causes problems and I copied everything from DataModule to MainForm. I set the actions carefully like they were before and now menu items work but open-button does not. The exact same action is triggered by menuitem but not by button!
So, this refactoring didn't solve any problems but created a new one.

And then: before the program closes it writes recent files to registry. It gives an error when writing a string, although I can find the "reg.xml" file it wrote. The same thing works in my small test project without errors.

All the program's behavior is defined in project file, pascal source code and form files. Am I correct?
So, WHAT CAN CAUSE SUCH PROBLEMS? I have used many many hours already trying to solve this.
The program itself is not very important now, I could as well forget it. I just feel uncomfortable when there are errors which I can't explain. Besides I am supposed to improve Delphi converter but now I am not even able to convert a program myself...

My tests happened on Linux, with GTK2 and QT. If someone likes to look at the code, please do this:

? $ git clone git://github.com/JuhaManninen/Pascal.git

It is not big.
At least it should be easy to verify the MainForm.OpenButton doesn't work while it should, even though the program hasn't done anything yet.

Regards,
Juha

Mattias G?rtner wrote

Do you mean the IDE becomes unstable because of a RunError in a debugged program?

Yes, sometimes, not always.
The console output (below) came when closing Lazarus. The application had closed shortly before. I also saw Lazarus crashing without closing it, so it really was unstable.

Now when I tested with GTK2 version of Lazarus I didn't see it happening. So, this can be because QT bindings are under heavy development. (Zeljko, if you need a good crash test, try my EssModel port :-))

RunError are critical. There is something very wrong in the code (e.g. dangling poniter, unintialized variable, etc). Please compile with all checks.

All checks are on:
I/O
Range
Overflow
Stack
Verify method calls

The unit and include paths are long but they should be OK. Other unit files:
Components/;CodeProvider/;Integrator/;Integrator/Code/;Integrator/Code/Delphi/;Integrator/CodeIO/;Integrator/CodeIO/JavaClass/;Integrator/Doc/;Integrator/Export/;Integrator/View/;Integrator/View/RtfdDiagram/;Model/;System/ Include files:
Components/;CodeProvider/;Integrator/;Integrator/Code/;Integrator/Code/Delphi/;Integrator/CodeIO/;Integrator/CodeIO/JavaClass/;Integrator/Doc/;Integrator/Export/;Integrator/View/;Integrator/View/RtfdDiagram/;Model/;System/

There is a RunError, then some exceptions including wrong typecast exception, and then access violation when the program flow reaches this:

    crkObj := TCrackControl(C);

C's type is TControl and crkObj's type is TCrackControl.
It passes this test :
  if C is TControl then
    crkObj := TCrackControl(C);

There should be no situation that code raises a wrong typecast exception, or the other errors, after passing the test.

I debugged the code a lot and saw this problem only with TCrackControl(...) typecast. Earlier I complained about loosing my mouse and key controls but that was because I hit the breakpoint inside a MouseDown handler and it disabled the mouse commands somehow (and I could not use keys because the editor window didn't have focus).

Juha

-----------------------

TApplication.HandleException Access violation
Stack trace:
$080719DC
$08139524 line 144 of include/lclintf.inc
$081B50A6 line 123 of widgetset/wsimglist.pp
$081B5420 line 210 of widgetset/wsimglist.pp
$08152F17 line 470 of include/imglist.inc
$08152E7E line 461 of include/imglist.inc
$08225DE3 line 350 of include/toolbutton.inc
$081D4C84 line 64 of include/graphiccontrol.inc
$0806C69A
$081CC818 line 1078 of include/control.inc
$081C3BAD line 4860 of include/wincontrol.inc
$081C3975 line 4797 of include/wincontrol.inc
$081C6E79 line 6700 of include/wincontrol.inc
$081D50E2 line 113 of include/customcontrol.inc
$0806C69A
$081C4979 line 5284 of include/wincontrol.inc
$0824D8E9 line 2932 of qtwidgets.pas
TApplication.HandleException Access violation
Stack trace:
$080719DC
$0820D293 line 789 of include/promptdialog.inc
$0820DC57 line 939 of include/promptdialog.inc
$0820DCFC line 952 of include/promptdialog.inc
$080BF777 line 11968 of main.pp
$080CB4A8 line 15827 of main.pp
$08088788 line 633 of include/application.inc
$08087F6F line 353 of include/application.inc
$0826090C line 12098 of qtwidgets.pas
$081FB3A5 line 272 of qtlclintf.inc
$08139BEA line 337 of include/lclintf.inc
$0820B019 line 177 of include/messagedialogs.inc
$0845F62D line 2697 of project.pp
$080B00A1 line 7223 of main.pp
$080B79A4 line 9636 of main.pp
$080BBC5B line 10904 of main.pp
$080B9BF9 line 10318 of main.pp
QPainter::end: Painter ended with 2 saved states
TApplication.HandleException: there was another exception during showing the first exception
Stack trace:
$080719DC
$081B507E line 120 of widgetset/wsimglist.pp
$081B5420 line 210 of widgetset/wsimglist.pp
$08152F17 line 470 of include/imglist.inc
$08152E7E line 461 of include/imglist.inc
$08225DE3 line 350 of include/toolbutton.inc
$081D4C84 line 64 of include/graphiccontrol.inc
$0806C69A
$081CC818 line 1078 of include/control.inc
$081C3BAD line 4860 of include/wincontrol.inc
$081C3975 line 4797 of include/wincontrol.inc
$081C6E79 line 6700 of include/wincontrol.inc
$081D50E2 line 113 of include/customcontrol.inc
$0806C69A
$081C4979 line 5284 of include/wincontrol.inc
$0824D8E9 line 2932 of qtwidgets.pas
$0824BBA2 line 1993 of qtwidgets.pas
[TMainIDE.Destroy] A
TApplication.HandleException: there was another exception during showing the first exception
Stack trace:
$080719DC
$086E9354 line 350 of ../debugger/cmdlinedebugger.pp $086E9139 line 275 of ../debugger/cmdlinedebugger.pp $086FEF6B line 3635 of ../debugger/gdbmidebugger.pp $086F70A9 line 1356 of ../debugger/gdbmidebugger.pp $086F6C81 line 1274 of ../debugger/gdbmidebugger.pp $086F6BB2 line 1253 of ../debugger/gdbmidebugger.pp $084BF791 line 2558 of debugmanager.pas
$0809BDEE line 1395 of main.pp
$0806C212
$0807C34D line 1686 of forms.pp
$08070299
$0824D990 line 2940 of qtwidgets.pas
$0824BBA2 line 1993 of qtwidgets.pas
$0825C72A line 10306 of qtwidgets.pas
$0825D0B0 line 10623 of qtwidgets.pas
$B7771B9E line 40 of src/qlclabstractscrollarea.h
lazarus.pp - unhandled exception
[TMainIDE.Destroy] A
[FORMS.PP] ExceptionOccurred

Mattias Gaertner wrote

Did you notice that there are two OpenButton? One has the action, the other not.

Damn yes!
I actually noticed the other button on a frame but I didn't realize it hides the MainForm button completely. Strange design.
One mystery solved.
You are clever!

Juha

No, you can't commit (push) your changes directly to my repository. The GitHub "free plan" account allows only one personal repository and no other direct committers. However, it allows you to fork any number of existing repositories, change them and then send pull requests.

The flow is explained nicely here:
http://jagregory.com/writings/git-remotes-contributions-and-the-letter-n/

I am also learning this now and I would be happy to test with your pull request. It should be easy:

First, at http://github.com:
1. Create a "free plan" account.
2. Find my Pascal repository.
3. Click the Fork-button. Now you have a forked Pascal repo.

Then at your machine:
 $ git clone git://github.com/YourName/Pascal.git
 Edit code ... git commit ... repeat if needed.
 $ git push origin

Then again at http://github.com:
Select your forked Pascal repo and click "Pull Request" button. There should be my name selected automatically.

It is actually cool. I was wondering how git users can pull from each other when most people have dynamic IP addresses. GitHub is one way to solve that.

Thank you very much for your incredible work you did for the DelphiToLazarus

Convertion stuff !!!!

Thanks for the positive feedback but the converter is not so incredible yet. The form file conversion fails on most non-trivial Delphi projects. Needs much more work.

The converter will never be perfect. I mean it can't do a fully automatic conversion. This EssModel prog is a good example. I can't convert it even manually after days of debugging. It would never happen automatically.

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100504/ec6fa2c9/attachment-0001.html>

Mattias G?rtner wrote

Can you create a small example to reproduce the problem?

The open-button problem got solved but the others remain.

I made test projects to reproduce the TControl typecast error and the TRegistry save error. They both worked well so I can't reproduce.

TControl typecast problem is especially strange. During debugging I verified once the control was the MainForm itself. Still it created the same error.

Maybe the program worked only by accident.

Yeah. The fact is that I compiled the original source with Delphi2009 and it didn't work either. It showed only a gray canvas. Binary download was built with Delphi6. It worked.

A lot of files use windows codepages. Maybe the converter could try to fix that automatically?

How does it show? I didn't see any problem regarding source codepages.

Regards,
Juha

Can you create a small summary how to reproduce the crash?

> Maybe the program worked only by accident. Yeah. The fact is that I compiled the original source with Delphi2009 and it didn't work either. It showed only a gray canvas.

So does LCL on gtk2.

Binary download was built with Delphi6. It worked.

Well, binaries, ...

> A lot of files use windows codepages. Maybe the converter could try to > fix that automatically? How does it show? I didn't see any problem regarding source codepages.

The files are not UTF8 encoded and contains umlaute in the comments. This is not important for this project, but in general the converter should at least have an option to convert to UTF8 because the LCL strings expect that.

Mattias

Hello Lazarus-List,

Tuesday, May 4, 2010, 12:41:13 PM, you wrote:

JM> I made test projects to reproduce the TControl typecast error and the JM> TRegistry save error. They both worked well so I can't reproduce. JM> TControl typecast problem is especially strange. During debugging I verified JM> once the control was the MainForm itself. Still it created the same error.

Had you tried to use heaptrc to detect memory corruption ? There is also a more agressive heaptrc option that do not reuse memory blocks that could be very good in this case but needs heaptrc recompilation.

Mattias Gaertner wrote

Can you create a small summary how to reproduce the crash?

Just opening any file (Delphi project or a single .pas file) always gives an error when hitting line

    crkObj := TCrackControl(C);

in function TessConnectPanel.AddManagedObject

or similar typecasts.

I updated the git repo with a working open button. :-)

The files are not UTF8 encoded and contains umlaute in the comments. This is not important for this project, but in general the converter should at least have an option to convert to UTF8 because the LCL strings expect that.

Ok.

Juha

They way I format the my source-code and and ess-model is a good example why such things are important

Original:
******
procedure TessConnectPanel.DblClick;
var
  found: TControl;
begin
  inherited;
  found := FindLCLWindow(Mouse.CursorPos);
  if Assigned(found) then
  begin
    FindManagedControl(found);
    if found  Self then
      TCrackControl(found).DblClick;
  end;
end;
The same with my formating-style:
**************************
procedure TessConnectPanel.DblClick;
var
  found: TControl;
begin
  inherited;
  found := FindLCLWindow(Mouse.CursorPos);
  if not Assigned(found) then exit;
  FindManagedControl(found);
  if found = Self then exit;
  TCrackControl(found).DblClick;
end;

Much better to read, and you see at once, that "FindManagedControl" looks strange!

There is only one rule that applies for all programmer's! We read source-code from top-down. That's why I try to avoid "else"-statements.

Dear friends:

I want to have the application with icon. In others application I can get but here I can?t.

The message is error when linking.

Please, any help will be appreciate. I dont have deep knowledge in compilation.

thanks in advance,

Ing. H?ctor F. Fiandor Rosario

05.05.2010 1:21, hector fiandor ?????:

Compiles and runs OK here (Lazarus 0.9.29/Windows). Probably you are running another instance of its executable, which makes it fail while linking.

Yes, because you enabled 'verify method calls' -CR. Disabling this gives a class diagram under gtk2.
Looks promising.

Mattias

dear Ganetsky:

I?m sending again the prove to know where is the error in the .rc file.

without icon it compile well, but with icon don?t.

thanks in advance

yours

Ing. H?ctor F. Fiandor Rosario

Mattias Gaertner wrote

Yes, because you enabled 'verify method calls' -CR. Disabling this gives a class diagram under gtk2. Looks promising.

Wow, I guessed it is some small thing and then I would feel stupid. :-)

Now I need to understand this. What does 'verify method calls' option do? There was a typecast, not a method call.
Is it by design that this option creates RunError and other errors and crashes the program when there is a typecast, or is it a bug? Doesn't look very useful option to me.

Anyway, this was not the original main problem with EssModel (fortunately because then I would feel very stupid). First it didn't draw anything. I changed the project settings later.
I still think the complex interface system was the problem for both Delphi2009 and for FPC. EssModel used also delegated interfaced methods. There must have been some change in Delphi regarding interfaces.

The interfaces were used to make some kind of model-view system between the model and the visual controls showing it. I replaced interfaces with Listener classes. How do other Delphi / Lazarus programs do such things?

Mattias mentioned at forum a need for a class diagram component. What kind of component? Would it be integrated in Lazarus IDE?

A (more or less) working version can be found in my GitHub repo. Anybody is welcome to

Jos? Mejuto wrote

Had you tried to use heaptrc to detect memory corruption ? There is also a more agressive heaptrc option that do not reuse memory blocks that could be very good in this case but needs heaptrc recompilation.

I must admit I never used heaptrc before. Now I did. There is even a switch for it in project settings.
The program still raises an exception when writing to TRegistry (uses XML file under Linux). The error listing below comes after just opening and closing EssModel. If I also create a diagram with EssModel, the listing is much longer.
How to interpret it? Where is the actual error?

I also get strange hints when compiling the project. They basically say that none of the project units were used, while they certainly are.

Would you care to take a look at the project?

Regards,
Juha

---------------------- Compiler hints : -----------------------

essmodel.lpr(38,39) Hint: Unit "uListeners" not used in EssModel
essmodel.lpr(41,31) Hint: Unit "uModel" not used in EssModel
essmodel.lpr(42,52) Hint: Unit "uCodeProvider" not used in EssModel
essmodel.lpr(43,52) Hint: Unit "uFileProvider" not used in EssModel
essmodel.lpr(44,53) Hint: Unit "uCodeParser" not used in EssModel
essmodel.lpr(45,57) Hint: Unit "uDelphiParser" not used in EssModel
essmodel.lpr(46,59) Hint: Unit "uCodeIntegrator" not used in EssModel
essmodel.lpr(48,71) Hint: Unit "uRtfdComponents" not used in EssModel
essmodel.lpr(49,65) Hint: Unit "uRtfdDiagram" not used in EssModel
essmodel.lpr(52,43) Hint: Unit "uModelEntity" not used in EssModel
essmodel.lpr(53,51) Hint: Unit "uParseTree" not used in EssModel
essmodel.lpr(55,78) Hint: Unit "uDiagramFrame" not used in EssModel
essmodel.lpr(56,102) Hint: Unit "uRtfdDiagramFrame" not used in EssModel
essmodel.lpr(57,39) Hint: Unit "uIterators" not used in EssModel
essmodel.lpr(58,42) Hint: Unit "uDocGen" not used in EssModel
essmodel.lpr(59,47) Hint: Unit "uDocumentation" not used in EssModel
essmodel.lpr(61,61) Hint: Unit "uJavaClass" not used in EssModel
essmodel.lpr(62,54) Hint: Unit "essConnectPanel" not used in EssModel
essmodel.lpr(63,51) Hint: Unit "uXmiExport" not used in EssModel
essmodel.lpr(64,42) Hint: Unit "essLayout" not used in EssModel
essmodel.lpr(65,50) Hint: Unit "uHtmlDocGen" not used in EssModel
essmodel.lpr(68,32) Hint: Unit "uConst" not used in EssModel
essmodel.lpr(69,52) Hint: Unit "uAboutForm" not used in EssModel
essmodel.lpr(70,60) Hint: Unit "uRegisterExtension" not used in EssModel
essmodel.lpr(71,61) Hint: Unit "uSettingsForm" not used in EssModel
essmodel.lpr(73,81) Hint: Unit "uTreeViewFrame" not used in EssModel
essmodel.lpr(76,60) Hint: Unit "uZoomFrame" not used in EssModel
essmodel.lpr(77,67) Hint: Unit "uOpenFolderForm" not used in EssModel

---------------------- heaptrc errors : ----------------------

[DBGTGT] TApplication.HandleException Failed to set data for value "RecentFiles"
[DBGTGT] Stack trace:
[DBGTGT] $08274418
[DBGTGT] $0827488D
[DBGTGT] $080A86FF line 144 of System/uconfig.pas [DBGTGT] $0808F3B7 line 188 of System/umainform.pas [DBGTGT] $080816F8 line 868 of include/customform.inc [DBGTGT] $0807FDDHeap dump by heaptrc unit
[DBGTGT] 8638 memory blocks allocated : 706318/727880 [DBGTGT] 8611 memory blocks freed : 705662/727152 [DBGTGT] 27 unfreed memory blocks : 656
[DBGTGT] True heap size : 458752
[DBGTGT] True free heap : 455920
[DBGTGT] Should be : 456296
[DBGTGT] Call trace for block $B51E3C60 size 48
[DBGTGT] $081E4152 line 90 of qtobject.inc
[DBGTGT] $08148754 line 135 of customtimer.pas
[DBGTGT] $08148900 line 212 of customtimer.pas
[DBGTGT] $080BEBFB line 88 of System/ufeedback.pas [DBGTGT] $08148885 line 181 of customtimer.pas
[DBGTGT] $081487EF line 156 of customtimer.pas
[DBGTGT] $0825C60C line 3875 of qtobjects.pas
[DBGTGT] $B7F40C7E
[DBGTGT] Call trace for block $B4235980 size 20
[DBGTGT] $0808F2D0 line 171 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] $080AFDD8 line 496 of Components/essconnectpanel.pas [DBGTGT] Call trace for block $B51EB380 size 58
[DBGTGT] $080A1909 line 121 of Integrator/View/RtfdDiagram/urtfddiagram.pas [DBGTGT] $0809D1F3 line 124 of Integrator/View/uviewintegrator.pas [DBGTGT] $0808F284 line 168 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] Call trace for block $B7FCE3E0 size 16
[DBGTGT] $080702E8
[DBGTGT] $080A8A50 line 163 of Integrator/View/udiagramframe.pas [DBGTGT] $080A94D7 line 61 of
Integrator/View/RtfdDiagram/urtfddiagramframe.pas
[DBGTGT] $080A17CB line 109 of Integrator/View/RtfdDiagram/urtfddiagram.pas [DBGTGT] $0809D1F3 line 124 of Integrator/View/uviewintegrator.pas [DBGTGT] $0808F284 line 168 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] Call trace for block $B51EA8D0 size 64
[DBGTGT] $0809D1F3 line 124 of Integrator/View/uviewintegrator.pas [DBGTGT] $0808F284 line 168 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] Call trace for block $B7FCD9C0 size 16
[DBGTGT] $080702E8
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] Call trace for block $B7FCDE40 size 16
[DBGTGT] $080C6937
[DBGTGT] $0817F73D
[DBGTGT] $08093D29 line 514 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] Call trace for block $B7FCE260 size 9
[DBGTGT] $08093D29 line 514 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] Call trace for block $B7FCDF00 size 16
[DBGTGT] $080C6937
[DBGTGT] $0817F73D
[DBGTGT] $08093D12 line 513 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] Call trace for block $B7FCE1A0 size 9
[DBGTGT] $08093D12 line 513 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] Call trace for block $B7FC0910 size 8
[DBGTGT] $080A6A1D line 204 of Model/umodelentity.pas [DBGTGT] $08093D01 line 512 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] Call trace for block $B7FCE380 size 16
[DBGTGT] $080C6937
[DBGTGT] $0817F73D
[DBGTGT] $080A6A08 line 203 of Model/umodelentity.pas [DBGTGT] $08093D01 line 512 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] Call trace for block $B7FCE440 size 9
[DBGTGT] $080A6A08 line 203 of Model/umodelentity.pas [DBGTGT] $08093D01 line 512 of Model/umodel.pas
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] Call trace for block $B7FCF990 size 40
[DBGTGT] $08093648 line 393 of Model/umodel.pas
[DBGTGT] $080933FF line 363 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] Call trace for block $B7FCE860 size 16
[DBGTGT] $080C6937
[DBGTGT] $0817F73D
[DBGTGT] $08093512 line 382 of Model/umodel.pas
[DBGTGT] $080933E7 line 362 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] Call trace for block $B7FCE7A0 size 9
[DBGTGT] $08093512 line 382 of Model/umodel.pas
[DBGTGT] $080933E7 line 362 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] Call trace for block $B7FBF510 size 8
[DBGTGT] $080A6A1D line 204 of Model/umodelentity.pas [DBGTGT] $08093501 line 381 of Model/umodel.pas
[DBGTGT] $080933E7 line 362 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] Call trace for block $B7FCBC80 size 16
[DBGTGT] $080C6937
[DBGTGT] $0817F73D
[DBGTGT] $080A6A08 line 203 of Model/umodelentity.pas [DBGTGT] $08093501 line 381 of Model/umodel.pas
[DBGTGT] $080933E7 line 362 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] Call trace for block $B7FCBB60 size 9
[DBGTGT] $080A6A08 line 203 of Model/umodelentity.pas [DBGTGT] $08093501 line 381 of Model/umodel.pas
[DBGTGT] $080933E7 line 362 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] Call trace for block $B7FCFA00 size 36
[DBGTGT] $080933E7 line 362 of Model/umodel.pas
[DBGTGT] $08092FAD line 296 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] Call trace for block $B7FCBBC0 size 16
[DBGTGT] $080C6937
[DBGTGT] $0817F73D
[DBGTGT] $08092F9F line 295 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] Call trace for block $B7FCBB00 size 9
[DBGTGT] $08092F9F line 295 of Model/umodel.pas
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] Call trace for block $B7FCBAA0 size 17
[DBGTGT] $0808F254 line 167 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] Call trace for block $B5098880 size 77
[DBGTGT] $080BE8FC line 60 of System/ufeedback.pas [DBGTGT] $0808F21F line 166 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] Call trace for block $B7FCBE00 size 24
[DBGTGT] $0808F21F line 166 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 line 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] $08121BF4 line 3063 of lresources.pp
[DBGTGT] Call trace for block $B51EA960 size 58
[DBGTGT] $0808F1BE line 163 of System/umainform.pas [DBGTGT] $08081553 line 831 of include/customform.inc [DBGTGT] $0807FD57 line 79 of include/customform.inc [DBGTGT] $08085799 line 2645 of include/customform.inc [DBGTGT] $0808CB28 line 2076 of include/application.inc [DBGTGT] $0805D117 lineC line 99 of include/customform.inc [DBGTGT] $0807FE11 line 113 of include/customform.inc [DBGTGT] $0806B5B2
[DBGTGT] $0807D0AD line 1684 of forms.pp
[DBGTGT] $0806F639
[DBGTGT] exception at 08274418:
[DBGTGT] Failed to set data for value "RecentFiles". [DBGTGT] 81 of essmodel.lpr
[DBGTGT] $B7C67ACE
[DBGTGT] $0823965F line 218 of imagelistcache.pas [DBGTGT] Call trace for block $B7FC9FA0 size 16
[DBGTGT] $080BECBF line 112 of System/ufeedback.pas [DBGTGT] $0806F564
[DBGTGT] $B7C67ACE

Juha Manninen wrote

I must say I like the original indented formatting more. Indentation carries information by itself. Your formatting loses that information.

I agree.

... and there was no "else"-statements.

Thanks for confirming that, I thought I was going blind. :-)

Ok, I don't want to argument about formating.
But did you see that the call to FindManagedControl(found); is useless ?

Zitat von Juha Manninen :

Yes, the description is misleading. Original is "Verify object method call validity", which is longer without being more clear. AFAIK it only checks class typecasts.

Is it by design that this option creates RunError and other errors and crashes the program when there is a typecast, or is it a bug?

It works like range checking. It raises an exception. If you don't catch it the default handler will stop the program.

Doesn't look very useful option to me.

It is very useful. It correctly found the invalid type cast. For these rare cases you normally disable checks. I don't know the flags for -CR, but here is an example for range checks:

   {$IFOPT R+}{$DEFINE RangeChecking}{$ENDIF}
   {$R-}
   while AString[p]#0 do inc(p);
   {$IFDEF RangeChecking}{$R+}{$UNDEF RangeChecking}{$ENDIF}

or you could use push and pop.

The code uses some dirty tricks that are doomed to fail with newer Delphi versions, and even more to port to FPC and other platforms. I think it is a bad example for testing the converter.

The interfaces were used to make some kind of model-view system between the model and the visual controls showing it. I replaced interfaces with Listener classes. How do other Delphi / Lazarus programs do such things?

see for example tiopf.

Mattias mentioned at forum a need for a class diagram component. What kind of component? Would it be integrated in Lazarus IDE?

Well, the codetools provide a lot of data. I would like to show class diagrams of units, packages and projects. I need a control to show graphs with hundreds (or even thousands) of nodes. Later we can add editing abilities.
The EssModel looks promising, but I have some doubts about the code quality.

A (more or less) working version can be found in my GitHub repo. Anybody is welcome to

Samuel Herzog wrote

They way I format the my source-code and and ess-model is a good example why

such things are important

strange!

There is only one rule that applies for all programmer's! We read source-

code from top-down.

That's why I try to avoid "else"-statements.

Thanks, I took out the useless FindManagedControl call. It was already in the original EssModel code.

I must say I like the original indented formatting more. Indentation carries information by itself. Your formatting loses that information. ... and there was no "else"-statements.

Anyway, it is a minor thing.

Regards,
Juha

Zitat von Juha Manninen :

I also get strange hints when compiling the project. They basically say that none of the project units were used, while they certainly are.

The units are not used in the lpr file. The Delphi IDE (mis)uses the dpr file as project file. The Lazarus IDE hides these hints.

Here is your error that raises an exception.
Wrong access to the registry.

[DBGTGT] $0808F3B7 line 188 of System/umainform.pas [DBGTGT] $080816F8 line 868 of include/customform.inc [DBGTGT] $0807FDDHeap dump by heaptrc unit

The exception is not handled properly and the code fails to clean up. (Missing try..finally). Each is listed by heaptrc.

[DBGTGT] 8638 memory blocks allocated : 706318/727880 [DBGTGT] 8611 memory blocks freed : 705662/727152 [DBGTGT] 27 unfreed memory blocks : 656

27 memory allocations were not freed. It should be 0.

[DBGTGT] True heap size : 458752 [DBGTGT] True free heap : 455920 [DBGTGT] Should be : 456296

For example a timer:

Beware the line info is not always reliable.

Mattias

Samuel Herzog wrote

Ok, I don't want to argument about formating. But did you see that the call to FindManagedControl(found); is useless ?

Yes, I commented it out and pushed to the repository. Later it can be removed with other cleanups. That is, if the program will be developed and maintained in future. Let's see...

Regards,
Juha

Mattias G?rtner wrote

The units are not used in the lpr file. The Delphi IDE (mis)uses the dpr file as project file. The Lazarus IDE hides these hints.

Ok, understand.

Thanks for the other comments. I will continue my practices later.

Juha

Mattias G?rtner wrote

Yes, the description is misleading. Original is "Verify object method call validity", which is longer without being more clear. AFAIK it only checks class typecasts.

So it should be renamed to "Verify class typecasts" or something.

For this program the best would be to get rid of typecasts. It would need more designing and refactoring again.

The code uses some dirty tricks that are doomed to fail with newer Delphi versions, and even more to port to FPC and other platforms.

Did you find other dirty tricks than the typecast trick for setting mouse events, and delegated interface methods?

I think it is a bad example for testing the converter.

Yes, it was way beyond testing the converter. I thought the manual conversion is easier. Then I became obsessed with it because I didn't understand what is going on. Now I understand more or less.

Ok.
I think the design of EssModel is OK but the authors implemented it in a too fancy way.

About the editing abilities you mentioned. Ideally the only editing should be to select the classes and methods etc. you want included. Then an advanced layout algorithm takes care of the rest.
Otherwise you have to relocate things in the diagram every time the class structure changes.

In my experience code generation from a diagram doesn't work very well in practice. Or maybe there are people who can use it but I got my classes screwed up completely by using the Delphi UML tool. Then I was afraid of the whole tool and didn't want to touch it.

There are now reverse engineering class diagram tools (but not for OP) with automatic layout calculation, like UMLGraph http://www.umlgraph.org/. It uses an external program (Graphviz) for layouting.

Juha

Zitat von Juha Manninen :

You can create a feature request on the fpc bug tracker.

I took only a quick look and I would be surprised if I already found all. I found that it used the dirty TCrackControl to get the event handlers to achieve another dirty trick called 'managed control'. Such things work only in projects knowing all used controls well. I guess the rest of the project took special care to let this work. Therefore

> I think it is a bad example for testing the converter. [...]

... which means you should not make this a public example for a converted project. There is no guarantee that it will work next year. Of course there are nice parts in it.

Yes, it needs good sorting and filtering options. Or zooming and fish eye techniques: show the current node at normal size and related smaller. Far related should be grouped.

I don't know anyone who do much UML modelling. But when we have a fancy class browser we can add some refactoring tools.

Mattias

I guess you're saying it is useless after studying the FindManagedControl function, right?

-Fl?vio

Fl?vio Etrusco wrote

I guess you're saying it is useless after studying the FindManagedControl function, right?

Yes. It only returns a "TManagedObject" wrapper for the given control, without any side effects. The returned value is not used here so it is clearly a useless call.

Anyway, the project has bigger problems than a useless function call. There is an ugly TCrackControl typecast trick which should be cleaned out if this program is going to be developed more.
I already changed it heavily to get rid of interfaces which often create problems in Delphi and FPC programs. It is a pity of course, proper interfaces would be useful.

You can look at the code yourself:

  $ git clone git://github.com/JuhaManninen/Pascal.git

Download from GitHub page should be possible, too.

Regards,
Juha

05.05.2010 13:17, hector fiandor ?????:

Again, it compiles fine for me.

BTW I see that path to your project has spaces (F:\HECTOR\juego del 15\deslizante1_FP\). Maybe this is the cause of your problem.

Dear Mr. Ganetsky:

BTW I see that path to your project has spaces (F:\HECTOR\juego del 15\deslizante1_FP\). Maybe this is the cause of your problem.

really, it was the bad boy: \juego del 15\

I have change to \juego_del_15\ and then pretty works.

Thanks very much.

If you want, I can send to your children a copy of the game for playing.

thanks again

Ing. H?ctor F. Fiandor Rosario

Anyway, the project has bigger problems than a useless function call. There is an ugly TCrackControl typecast trick which should be cleaned out if this program is going to be developed more.

Delphi goes a different route, by allowing access to protected (and even private?) members of classes by means of Extended RTTI. In any case the encapsulation of class fields and methods is broken; this encapsulation was designed for an interface between the component library and application code, not for code transformation, GUI designers or other "low level" stuff.

DoDi

I have this problem every day in development of MSEgui framework. Often there is need to access low level stuff in classes which are defined in other units.
I don't want to define the low level stuff public because it should not be used in application code.
I don't want to use a single unit for the whole framework because there are about 200'000 lines, I don't like include files, for the compiler it would be a single unit anyway.
And please don't suggest I should refactor the code in order to have no low level interactions between framework classes in different units. ;-) It is simply not possible, especially in a framework which evolves over a long time and where it is too dangerous and expensive to change the architecture often for additions which where not foreseen at the beginning.

Because of this I supposed several times the introduction of the simple construct of "friend units" where protected class members are visible. Nobody liked it :-( so MSEgui is full of code like:

"
uses
 classes,mseclasses,msegui;
type
 twidget1 = class(twidget);
 tcustomframe1 = class(tcustomframe);

[...]

 twidget1(thewidget).dosomething();
 tcustomframe1(frame).dosomeother();
"

With "friend units" it could be done for example like: "
uses
classes,mseclasses;
friends //or any other more appropriate identifier msegui;

[...]

 thewidget.dosomething();
 frame.dosomeother();
"

Public framework class elements are intended to be used by application code, protected elements in "friend units" can be used too but need a deeper knowledge of the context and are normally accessible by the framework only, private elements are for encapsulation purpose.

Martin

It is kind of dirty trick but now when think of it, it is rather reliable if the class structure doesn't change completely.
Like in case of EssModel, it was used to reach the members of TControl. All visual components are derived from TControl and that is not likely to change.

So, this trick is not something that will break the code at any moment in future, after all.

Juha

Juha Manninen wrote

It is kind of dirty trick but now when think of it, it is rather reliable if the class structure doesn't change completely.

It's the only way to sometimes get to protected methods or fields. Plus, if the two classes are not related, the FPC compiler will give you a warning - so it is rather safe to use. So I wouldn't regard it a "dirty trick" but simply a way of getting to what you need.