ESS-Model again

[dicepd]

This is a first cut to port ESS-Model to Lazarus and fpc.


Primary goals met on this iteration.

1: Produces Diagrams on screen with common mouse handling across Windows
Gnome and QT.
2: Has no other package dependancies than LCL.
3: Has no code which requires {$mode delphi} all files have {$mode objfpc}{$H+}
   to have a common a base as possible for cross platform.
4: Capable of parsing itself.
   ( parser is old, not expected to parse later dialects in first port)

Casualties .. functionality removed

html generation (violates 2: requires other units/libraries )
Delphi integration module ( not required )
WMF generation  (violates 2: requires other units/libraries )

Casualties ..

The Good:
1: Still as fast as delphi binary (at least on windows.)
2: Runs in Linux (only one {$ifdef LINUX} was required.)
3: Internal workings would suit event emitting style parser.
4: Code position is stored with model elements.
5: Suited to single file parsing.
6: It has scratched my itch. (To have something to view large packages,
   primarily GLScene)
7: Does not crash parsing modern pascal variants
   (throws lots of errors but does not crash)
8: Nothing else added at this point so a base for possibilities.
9: Reads .lpr for project (use read directory for packages).
10: Does what the windows binary does ( casualaties excepted ).
11: Does not leak mem.

The Bad.
1: Parser is old.
2: xmi is old, not found anything modern that will see the xmi as valid.
3: Missing key model features (Enums, Aggregation, Composition to name a few)
4: Crashes through dangling pointers to badly parsed entities.
   (Solution FIX THE PARSER don't add exception handling)
5: Mouse handling may not be optimal in Gnome as lots of calls to get parents
   of control under mouse, original program relied on mouse events not being
   caputured by owner drawn labels but used windows specific mechanisms which
   are not portable. I run my Linux test boxes in VMs so may be ok on bare
   metal.
6: Dragging when view is scrolled, original suffered this also.

There has been interest in the past in this, but I think this is the first attempt at true native
port with no deps.

Peter
 
EDIT Update file below in post 5, don't know how to remove this one!                                                           

[howardpc]

The .zip seems to be a missing unit uRegisterExtension.

[dicepd]

The .zip seems to be a missing unit uRegisterExtension.

This is the delphi integration, not required, remove it from project will try to find the dangling ref.

Peter

[dicepd]

Ok found it.
It is in uSettingsForm implementation uses line 60, just remove it.

[dicepd]

Ok my bad I have never been anywhere near the settings form up till now.

Lesson learned from today, removing a file from the project does not mean fpc will not compile it if it thinks it needs it, as it is in the project path.

Updated file included.

[JuhaManninen]

Cool!
Are you going to put it under revision control somewhere?

[dicepd]

Cool!
Are you going to put it under revision control somewhere?

If there is enough interest. ATM it is in my  local gitlab server.
Though I am not really in a position to take charge of a full blown project that
this would entail.
This was just a side project to distract me as I  have a mental block on the project I should be working on

[JuhaManninen]

If there is enough interest.

It depends on the design being suitable for future development. For example is it possible to fix the mouse event and view dragging issues with reasonable effort? If not then a whole new design and application would be better.
How about replacing the parser with fcl-passrc? Is it feasible?

Anyway, nobody has made any similar application. We would need one for Pascal.
If this version is developed further and put into a hosting site, it can have many admins / maintainers. Even I could be interested then.

[dicepd]

How about replacing the parser with fcl-passrc? Is it feasible?

Ok I have had a look at fcl-passrc and this looks faily easily doable. The architecture of the program allows for multiple parsers, so it should be possible to do a quick Interface read-only parser (current functionallity) but still not restrict the abilty to extend to a full read write parser using fcl-passrc.

I will have a go at the quick Interface read only parser, using a command line test program, to output to text what should be generated then integrate it.

As to the mouse issue I am not sure how much of an issue it is ( I was only going by the valgrind number of calls), but if it really is an issue it would be one that would have to be solved in another program anyway.

Peter

[jwdietrich]

Fortunately, it can also be compiled on macOS (Carbon widgetset).

On Mac, there seems to be a bug that results in a dialog box reporting "Ignoring unknown switch: -psn_0_458864", see attached screenshot.

[Phil]

On Mac, there seems to be a bug that results in a dialog box reporting "Ignoring unknown switch: -psn_0_458864", see attached screenshot.

Probably means it's looking at ParamStr(1), which will have a value like that on Mac.

[jwdietrich]

On Mac, there seems to be a bug that results in a dialog box reporting "Ignoring unknown switch: -psn_0_458864", see attached screenshot.

Probably means it's looking at ParamStr(1), which will have a value like that on Mac.

You are right. Responsible are the code lines 399 and 400 of uMainModule. They could be easily commented out, but I am unsure, if it has side effects.

[jwdietrich]

There is another issue with macOS: Clicking in the right pane of the model window raises a stack overflow, see attachment.

Edit: Obviously, the bug is in lines 854 to 856 of the unit essConnectPanel (method TessConnectPanel.OnManagedObjectMouseDown):

Code: Pascal  [Select][+][-]

1. pt := (Sender as TControl).ClientToScreen(pt);
2. pt := ScreenToClient(pt);
3. MouseDown(Button,Shift,pt.x,pt.y);

I doubt if it makes sense to convert the point from local coordinates to screen coordinates and back again in the subsequent line.

[dicepd]

I doubt if it makes sense to convert the point from local coordinates to screen coordinates and back again in the subsequent line.

Sender is the  method label on the class, XY are in it's Device context coords, This is converted to the coordinate system of the class box window and sent to the class box. This is required for gnome it will need some testing to see if the click is sent to the parent as well as the child in other OS's. Certainly the mouse move similar code causes problems in windows. As stated this may need looking at further, it was a case of trying to get something working.

Possibly this could be caused by managing to get a mouse event on the class box itself, so maybe a check for sender <> self is worth a try.

[dicepd]

I have done a first cut over of passrc as the parser and hopefully fixed up the mouse issue on Linux somewhat. So no crashes from dangling pointers anymore.

I have sent it down LCL. fcl and Components. Parser errors somewhat less than before and as it is a read then act stlye it is a little slower.

This cut over does not yet have project parsing, use directory for the moment.

Now hosted at https://github.com/dicepd/Laz-Model



Peter