TVPlanit Reboot

[wp]

@JD: You wrote somewhere above that you use TBufDSDatastore as a temporary storage and erase the db files afterwards. Then maybe the new property "Persistent" is interesting for you. Its default is true and results in the current behavior. But if it is false all data are held in memory, no need to delete anything...

[JD]

@JD: You wrote somewhere above that you use TBufDSDatastore as a temporary storage and erase the db files afterwards. Then maybe the new property "Persistent" is interesting for you. Its default is true and results in the current behavior. But if it is false all data are held in memory, no need to delete anything...

Just tested it. I like it. Thanks for your good work. By the way, I've noticed that are memory leaks in the examples. I built (in Debug mode) the bufdsdatastore and the inidatastore examples & they both reported memory leaks.

[wp]

Ah, thanks for reporting. But it was an easy one. Fixed.

[JanRoza]

@wp: As promised the dutch po file for the demo.

[wp]

Thanks.

[SunyD]

This component needs some work for including the image resources.
It includes all images in compiled programms, even the images for the lazarus-component-platte too.
Compile gadgets example and inspect the programmfile with resource editor.

[wp]

I don't see how including all images needed by the package internally to the final application could be prevented. But having the component palette icons in the resource definitely looks wrong. At the moment I don't see where this happened. Since I want to focus on other things I cannot investigate too much. Can you give me a hint, or, better, can you write a patch?

[SunyD]

I don't see how including all images needed by the package internally to the final application could be prevented. But having the component palette icons in the resource definitely looks wrong. At the moment I don't see where this happened. Since I want to focus on other things I cannot investigate too much. Can you give me a hint, or, better, can you write a patch?

Images for component palette included as *.res files. I find out lazarus/fpc include it in every programm if they are *.res/*.dcr files,
so images for component palette must be included as lazarus resources (.lrs-Files). I made for you lrs-file in zip-file.

Why have you added IDEIntf to required packages? Is it needed?
I think you should remove all unneeded units from laz_visualplanit.pas and put it to vpreg.pas,
because packageunits (here laz_visualplanit.pas) are included to every application if you this package.


1. Comment out {$R VpReg.RES} from this units:
VpRegF2.pas
VpRegAd.pas
VpRegIs.pas

Because one from vpreg.pas is enough.

2.  Open vpreg.pas and made this changes:
a)
  from
{$R vpreg.res} { Palette Glyphs           }
 
  to
{$ifndef FPC}
{$R vpreg.res} { Palette Glyphs           }
{$endif}

b)
Add to uses:
{$IFDEF LCL}
  LResources, ....

c)
at end of file:
{$ifdef FPC}
initialization
{$I vpreg.lrs} // Palette glyphs
{$endif}
end.


3. Make same from 2. to vpregzeos.pas but the resources for vpregzeos.pas named vpregzeos.res/lrs.


You find in zip-file the images and resources. (You don't need images now, maybe in future for changes).

[SunyD]

We should designtime and runtime packages. Package IDEIntf should placed in designtimepackage and removed from runtime package. Because with IDEINtf all images/forms from ObjectInspector/Propertyeditor will be included in the programm file. Look the images from the example gadgets below,  left compiled visualplanit without ideintf.
Right coints all images/forms from ObjectINspector and left is 2,39 MB right is 3,84 MB. 1,5 MB for useless data.

My  recommendation for package devoloper is:
- put component  images for component-palette in lrs-files not in res/dcr-files. (fpc includes res-files in every programm that uses this package.)
- seperate designtime with runtime-package, don't put IDEint in runtime packages.

[wp]

Yes, splitting off designtime code into a separate package is certainly the way to go. This is strictly enforced by Delphi now, but Lazarus still allows the combined runtime/designtime packages. Users, however, will not be very happy because they have to touch another package for installation...

I am not sure about the need to use lrs resources. I loaded several binaries of other Lazarus programs into the resource editor, and it is only the tvplanit programs which contain the palette icons. It must be related to the component and property editors registered along with the component registration. I would like to avoid using both lrs and res resources in the same package separated by an ugly IFDEF construction.

BTW Lazarus version vs. Delphi version: The current version in ccr still contains a lot of IFDEF FPC or IFDEF DELPHI, which suggests that the package would still compile with Delphi. I tried in an earlier stage of my work: it does not. Soner, I know that you have some experience with this package as well, what is your opinion: shouldn't these IFDEFs be removed in the long run to keep a pure Lazarus version? I think nobody will ever make the effort to make the package Delphi-compatible again.

[SunyD]

I am not sure about the need to use lrs resources. I loaded several binaries of other Lazarus programs into the resource editor, and it is only the tvplanit programs which contain the palette icons. It must be related to the component and property editors registered along with the component registration.

I think it is caused by lrs-resources. It tested it also with HtmlViewer-Components (https://github.com/BerndGabriel/HtmlViewer).
With lrs-Resources the images for component-palette and editor-forms are not included in programm file.

Soner, I know that you have some experience with this package as well, what is your opinion: shouldn't these IFDEFs be removed in the long run to keep a pure Lazarus version? I think nobody will ever make the effort to make the package Delphi-compatible again.

Yes, i think delphi compatibility can be dropped, noone goes back to delphi from lazarus.  I saw someone on github maintains turbo power controls for new delphi versions.
I think lazarus and fpc is good enough, the lazarus/fpc user sould forget delphi and concentrate to lazarus/fpc.

It is good to separete package if package contains own editors (IDEintf!). Here is more information about packages http://wiki.freepascal.org/Lazarus_Packages#Design_Time_vs_Run_Time_package

[Graeme]

I think lazarus and fpc is good enough, the lazarus/fpc user sould forget delphi and concentrate to lazarus/fpc.

Exactly! That's what I've done 9 years ago, and haven't regretted it ever. There is only one dual-compiler project I still maintain, and I must say it is a pain in the butt. Delphi does nothing to be Free Pascal compatible (even if FPC had the features first), so why bother the other way round! Free Pascal is by far good enough to stand on its own - it needs nothing from Delphi. The only thing Delphi has that is better, is a debugger.

[wp]

The new svn version of tvplanit has separate designtime and runtime packages. Now component palette images are no longer contained in the exe file (even with .res resource - file size is the same with .res and .lrs resources). The size of the gadgets demo decreases from 4.2MB to 3.0 MB (debugger symbols stripped).

In addition I moved the lpk files to the root folder of the libraray for better visibility.

Since the new version contains major changes with respect to package and compiled file locations I'd suggest to uninstall the old tvplanit package first. Then open the runtime package, "laz_visualplanit.lpk", in "Package/Open package file .pk" and compile. Then open the designtime package "laz_visualplanit_design.lpk" as well and click "Use" > "Install" to recompile the IDE with the new package.

Repeat with the zeos addon packages if you want them.

Please report any issues here - it is very easy to forget a local file to upload to the central repository. If everything is fine I'll create a new zipped release version soon.