Graeme Geldenhuys wrote

I'm pretty sure it will be easy to remove tiOPF dependencies from the RTFReport unit, so it can be used as a stand-alone (non tiOPF based) report engine.

Please, keep us informed when you remove the dependency ;-)

Luiz

I'm using in production and works well for relatively complex reports. I just missed the "child bands" and "shift" features from FastReports. There's only one report that needed that. The solution i found was to create a bridge app in Delphi that runs the report using FastReport. Not optimal but it works.

When i have time i'll take a look in fortesreport to see if can handle such report.

Luiz

Anyone using LazReport in production environment? I'd like to start doing more GUI based projects in Lazarus but lack of a good reporting tool is a deterrent for may types of projects that I do.

I tried it out about a year ago and there was some problems but I bet there's been some work done it in the interim.

Thanks,

Lee Jenkins wrote

Anyone using LazReport in production environment? I'd like to start doing more GUI based projects in Lazarus but lack of a good reporting tool is a deterrent for may types of projects that I do.

In tiOPF there is a RTFReport.pas unit that I ported to Free Pascal. It's a single unit, but is actually a full reporting engine. It allows you to report from tiOPF based Objects, other custom data or TDatasets. I design my reports templates using OpenOffice and save them in RTF format. The RTFReport engine then runs through the template populating it with data and store a completed report again in RTF format. In even has support for adding custom functions, calculated fields etc in the reports.

I prefer using OpenOffice for designing and viewing reports, because when you launch OpenOffice to view the report, you can put it in read-only mode which hides most of the toolbars and menus and it actually looks like a "print preview" report viewer. MS Office does not do this. Even though I use OpenOffice, any application that can read/write RTF files. But OpenOffice is free and our clients seem to like it too.

I'm pretty sure it will be easy to remove tiOPF dependencies from the RTFReport unit, so it can be used as a stand-alone (non tiOPF based) report engine.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Sorry if this is the wrong place to discuss language issues.

I saw the following on the ADUG Delphi list and wondered if there was a possible Lazarus feature here.

Cheers
Lance
------------------------------------------------------------------------------------------------

How can you avoid circular references with two modules that interact with each other?

This has been discussed before in the Delphi newsgroups and it has been requested of BIBCE (Borland/Inprise/Borland/CodeGear/E9o) several times. IIRC there may be a QC entry.

Basically it should be possible with a minor language change and not too much effort from the compiler team. Something like:

unit ParentObject;
interface
TChild = forward class; // My made-up syntax
// or TChild = implementation class; or some other syntax!
TParent = Class
public
   property Child :TChild;
end;
implementation
uses ChildObject;
// Nothing special here, only need the love one-way
// but you could do it both ways if you want
unit ChildObject;
interface
uses ParentObject;
TChild = Class
public
   property Parent :TParent;
end;

"TChild = forward class" tells the compiler that TChild is a class, and the complete type information is known in the implementation section (which the compiler can validate). That's all the compiler needs to know in the interface section - essentially it needs to know the kind and size of the type. It doesn't require a two-pass compiler or any other extreme make-over.

This feature is often needed and the "if you need to do that then something is wrong with your design" argument doesn't fly with me. It's one of the C++ features that I wish Delphi had. I'm holding out for D2011 - perhaps the new compiler will have it!

Lance Collins wrote

Sorry if this is the wrong place to discuss language issues.

Probably the fpc-dev mailing list.

> How can you avoid circular references with two modules that > interact with each other?

[...snip...]

This feature is often needed and the "if you need to do that then something is wrong with your design" argument doesn't fly with me.

I can't agree more. Sometimes there is a valid design for something like that. The compilers already handle forward declarations in the same unit, so why can that not be applied for multiple units as well. And if the forward declaration is not fully resolved by the time the whole project or unit is compiled - raise a compiler error.

The current usage of forward declaration is exactly the same principle we are trying to use, but this time just across units.

Regards,
- Graeme -

This is the world upside down. Better tell us exactly why you think this must be possible. the 'Sometimes there is a valid design for something like that' is not an there are other - more valid - ways to
accomplish what you want.

Michael.

I can give you loads of examples where I had to implement workarounds in Object Pascal to get around that "limitation".

Have ever tried to write code in a similar fashion as Java does? One class per unit. You will hit that issue very quickly. What about having two-way referencing in objects: Customer.GetOrders and Order.GetCustomer. Or Many-to-Many relationships.

For all these you need to revert to Interfaces or use base classes (TObject or TtiObject) and do lots of casting in the implementation section. These are all workarounds for a language (compiler) limitation, which does not exist in other languages like C++ or Java. Alternatively you have to use one HUGE model.pas unit and all your various business classes in there - and maybe even structured via include files and have lots of forward declaration at the top of the model.pas unit. Problem then is that any class can reference any Private or Protected fields in other classes. :-(

Regards,
- Graeme -

Michael Van Canneyt wrote

This is the world upside down.

So why is forward declarations allowed? It's the same principle!

Regards,
- Graeme -

No, because I write object pascal, not Java.

One class per unit. You will hit that issue very quickly. What about having two-way referencing in objects: Customer.GetOrders and Order.GetCustomer. Or Many-to-Many relationships.

The two way referencing can easily be solved with a forward class declaration, where the implementation follows in the interface section. See TCollection/TCollectionitem.

If classes are so intertwined, then it seems only natural to put them in 1 unit IMHO. The private/protected issue is valid, though. Which is probably why Borland introduced 'Strict private' and 'Strict protected'.

Michael.

No, because the declaration is guaranteed to follow in the same unit. A unit forms a self-contained whole.

Unit loading is a difficult matter as it is. If you start spreading declaration and implementation over different units, I'm not sure that the compiler can guarantee correctness.

But Florian should answer this, he is more knowledgeable about the compiler internals.

Michael.

This is not how Object Pascal should be used. Or do you miss also GWBasic style per line labels ;)?

Those cross unit forward declarations open a can of worms which is probably worse than cyclic unit references in the implementation section. Its basic design flaw is that it makes the interface of an unit dependend on the implementation section and even worse, of the units used in the implementation section and their order! And this is usually a no-go.

It's easy to come up with some simple example which is easy to handle. On the other hand, the simple examples can be solved by other means like an abstract base class.

I'am sure there will be dozens of corner cases which confuse (and the programmer) the compiler like having a class defined in more than one unit. Or combine cross unit forwards with cyclic unit references, maybe even generics, sounds to be really dangerous and complicated on the compiler side to solve so slowing down the compiler.

Sorry if this is the wrong place to discuss language issues.

Yes, because you posted in the LazReport Status thread instead of starting a new one.

Michael Van Canneyt wrote

> > Have ever tried to write code in a similar fashion as Java does? No, because I write object pascal, not Java.

OO design patterns & principles apply across programming languages. You do not need to code in Java to use the same idea.

It's hard enough to implement well designed classes - and then having to fight the compiler too. One class (eg: TCustomer & TCustomerList) per unit is a clean design and help make unit testing so much easier.

But then again, I have managed for so many years - what's a few more. ;-)

Regards,
- Graeme -

Unit testing has nothing to do with pascal units and because a unit as a namespace on it's own, it makes no sense to put only one or two classes into one unit.

Actually, I think the current design is right.

the gains of a "class declared external" are far less than thought.

A class of which the details where only known in the implementation, may be allowed to be referred in the interface. But otherwise it would be like any other class that was declare in implemantation: a type local to this unit.

That is, if a unit with that trick, did try to use this forwarded declaration in any public section, or anywhere where it was accessible by units using this unit, then the problems would start.

Because if I am using unit XYZ, and access the public property or method ABC that refers to some class, then add this time this some class *must* be fully known (or the compiler will have to go into all kind of extra checks and whatever else).
If it was on public methods properties how would the compiler know that outside units are supplying the correct type? Only by reading the implementation, and then you will need multipass compiling....

So that a class can only be used for private stuff on this class. it can no be used for the customer/order relations, as they would require this internal class, on public methods/properties.

My 2 cents

Martin

Florian Klaempfl wrote

Unit testing has nothing to do with pascal units and because a unit as a namespace on it's own, it makes no sense to put only one or two classes into one unit.

It helps with the logical separation of classes, which in turn makes them easier to unit test.

Plus you don't have the Private and Protected issues I mentioned before.

Regards,
- Graeme -

How does it help ? I fail to see that. Whether or not a class is in a separate unit does not influence it's design at all IMHO. The editing process may be easier as there is less code to browse through, but that's about it.

Plus you don't have the Private and Protected issues I mentioned before.

That one can be solved with the 'strict' clause. That would help, because you cannot inadvertently use private/protected fields or methods of another class, and thus compromise your OOP design.

Michael.

I had to implement the State Pattern a while back and it was a pain because in order to avoid circular references, all the different state pattern objects had to be in the same unit. That is of course if you want to refer to the new State object's class when transitioning. Using a string to indicate which "registered" state to switch to would have allowed me to use different units but I didn't like that way of doing it.

Transitioning is done in the implementation and the abstract state doesn't have to know about its descendant states. Circular references in the implementation are allowed, so I don't see the problem.

Vincent

--- El dom 9-ago-09, Luiz Americo Pereira Camara escribi?:

For the rest of us that don't know what "child bands" or "shift" features do can you please explain it?

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Jesus Reyes wrote

For the rest of us that don't know what "child bands" or "shift" features do can you please explain it?

http://fast-report.com/documentation/UserMan/index.html?child_bands.htm

http://fast-report.com/documentation/UserMan/index.html?shifting_objects.htm

Luiz