Next target: EasyReport !!! :-)

[reinaldocrespo]

Antonio /Everyone;

I think it is good that FWH attempts to get its own reporting engine. However, FWH should be made so that it can work with other 3rd party libraries that are available to other languages such as Delphi or Builder. If Codejock or FastReport (or Crystal Reports for that matter) don't work well with FWH, then efforts should be made so to fix that. Again, nothing wrong with providing its own reporting engine even if it is a far cry from FastReports.

In my opinion, Antonio/FiveTech should continue to try to acquire ER as well as trying to negotiate with FR so that he reaches a similar deal as Sergey did or as xalier now also has. Likewise with other 3rd parties such as CodeJock. If someone prefers to use ER, then fine, do so. For others who are willing to pay for a much more robust, well documented and professional reporting engine, then the fact that we are developing with FWH shouldn't be the roadblock. BTW- you should know that it isn't uncommon to find IT managers who already know how to change and create reports using FR and their documentation is vast and very complete.

Hope you can all understand that isolating ourselves in such manner that we can't take advantage of other professional grade 3rd party components such as CodeJock and FR is a mistake. (other xbase environments have already been made compatible with current versions of FR -Just FYI).

With my best regards,


Reinaldo.

[Antonio Linares]

Reinaldo,

IMO, the fact that we are trying to acquire ER, it is not related at all with the fact that FWH is already compatible with other reports engines, as many of you are already using those other report engines that you mention.

In other words, you are free to use whatever report engine you want to. Thats fine. But in the case with ER, what we want is that all FWH users have already a great report engine included for free with FWH.

And the real advantage of using ER is that we will have its full source code so we will be able to enhance it, modify it, fix it, etc. something which it is totally impossible using a closed commercial reports engine, where you don't have their source code, and just have a closed DLL that if for any reason it gets discontinued, you will have no way at all to do anything at all.

As an example, please compare xbase++, or Visual dBase, or Visual FoxPro, or CAVO, or VB, etc. with the compiler that we all use today: Harbour. Whats the difference ? Why did you choose you use Harbour ? Because it is free, it is open source code, and we do know that it will exist for ever

[reinaldocrespo]

Regarding why I (or most everyone else here) choose (x)Harbour, I don't think it has anything to do with the fact that it is open source and more to do with the fact that FW allowed us to continue writing Clipper code. I'm sure most here, like me, tried other avenues to arrive at Windows apps, but soon discovered that with FW we were able to stop the non-sense and stay with the compiler we already knew and loved so well. I'm pretty sure that most people here feel it is already too late to start learning CAVO, or Delphi, or Builder or even .NET and that is why we've stayed with FWH. But you won't find new programmers coming from .Net or Delphi joining forces with our old and almost forgotten Clipper even if it is free and multi-platform.

It should maybe be noted that FW is not open source nor is it GPL nor is it free. And, that people are not using FW because most of the source is open or free (as it is not).

I don't argue against ER. I love the idea and congratulate the effort. I think it breaths new life into the community and hope it will soon become another tool available to us. I do wish to highlight that other much **smaller** and lesser known xbase environments have been able to make arrangements with FR to re-distribute the latest versions. Perhaps it will make FW stronger if we follow suite.

Reinaldo.

[lucasdebeltran]

Reinaldo,

What versión of FastReport are you using?.

Besides, it can´t be used in FWH 64 bits as you don´t get the source code.

[Antonio Linares]

Dear Reinaldo,

Would you mind to answer these questions ?

1. What would have been of FWH without Harbour ? What compiler would have you used with it ?

2. Why Harbour became as popular as it is today ?

3. In FWH, what do you get in source folder ?

4. What was the reason for many FWH users being able to fix FWH bugs theirselves ?

5. What made possible that many FWH users wrote their new FWH classes of their own ?

6. What does stop us to use FR if we want to ?

7. Could points 3, 4 and 5 be aplied to FR ?

8. Are points 3, 4, and 5 applayable to ER ?

Please excuse me if I am so "logical", but we are programmers

[Antonio Linares]

Reinaldo,

I know that your wish is a very good one: that we have our own support for FR, and we will have it, don't worry about it. Because we can do it if we want to.

But for now, lets focus on the deal to have a great FWH + Harbour Visual Reporting engine, full source provided that will remain alive, used and enhanced for many years to come

And all your help is really welcome

[Enrico Maria Giordano]

Reinaldo,

I'm sure most here, like me, tried other avenues to arrive at Windows apps, but soon discovered that with FW we were able to stop the non-sense

You found the right word: non-sense. Using most of "mainstream" programming tools is nothing else than "non-sense". Unfortunately, new young programmers can't see this fact...

EMG

[TimStone]

Reinaldo,

Two points:

1) FWH works with many 3rd party products like Codejock. I have a QuickBooks interface, use a separate PDF library that works very well, and interface with many 3rd party products. My appointment scheduler is done with Codejock.

2) The efforts published on this site actually work to expand our capabilities as many of us merge into FWH / Harbour / Visual Studio 2013 with good results. Also the focus on merging in traditional coding with SQL capabilities is in the same direction.

It is all about providing us with versatility, and the ability to have many options. For developers with low income clients, the cost of incorporating many 3rd party products can be prohibitive. For example, to obtain fixes for Codejock we need an annual subscription which is expensive. If we use 6 external resources, the cost can be very high. For some developers, that is not a possibility, so it is great to have these options available in FWH.

Tim

[Antonio Linares]

Tim,

+1

[reinaldocrespo]

Tim/Antonio/Lucas;

You all seem to not understand that I have nothing against integrating ER into FWH. That is not the point I'm making. I actually congratulate Antonio on the effort. "It breaths new live into FWH". Go back and re-read the post, this time find where is the argument against ER. I'm all for anything free -the sooner the better.

My point is totally different than you seem to understand. AMOF, Lucas questions only confirms my point -although he doesn't seem to see it. The fact that FW can't work with FR 64 bits using MSVC 64, is only a testament that fw needs to attend a looming problem on the horizon. Hopefully you do realize that most other programming environments DO work with FR64 as well as with all the latest versions of FR. It is not a lack of source code that makes fw inoperable with FR 64. Furthermore, and much to our own detriment, other xbase environments that are hardly known with a much smaller user base and that spawned out of our own fw-harbour community, do work with the latest versions of FR.

I may be wrong, but it seems like Michael Filipenko (FastReports Inc), is willing to make deals for FR resale. Sergey and now also that other visual-xbase environment that I make reference to, claim that their implementation will work with any (x)harbour -including FW and using the latest versions of FR. In other words, they are selling and promoting FR for FW among other (x)harbour environments. That might be the only alternative for FW users to access FR in the future, but I really hope not.

CodeJock is only used on my argument to help understand those who've never worked with FR but have seen the power and beauty of CodeJock, how 3rd party libraries saves the day for those facing professional competition and who are also willing to pay. I'm a CodeJock user myself. Remember it was actually me who wrote and shared the original code showing how to use CJ calendar control from xharbour. I shared the code with Tim and Richard while most others on this forum argued against CJ in favor of Calex. FYI- Calex was a project I started with Daniel but gave up after learning of CodeJock and realizing it was cheaper to purchase the control than to write it ourselves while also impossible to even come close to CJ's calendar quality. I can still hear today most arguments against CJ and in favor of Calex. These are the same arguments I'm hearing now regarding FR.



Reinaldo.

[Antonio Linares]

Reinaldo,

We are a small team, though very strong, and we don't have the time neither the resources to go for all the requirements that our users may ask for.

I fully understand your point of view: You want to use FR and you want FiveTech to fully suppor it. It makes perfectly sense.

But, please see it this way: We have already made a commitment with EasyReport (or at least we are doing our best try to get it, because very little money is arriving for now) and if this deal succeed for any reason, we have already made a commitment and we will do our best in order to make it a reality (if the money does not blocks us).

So I would say that you are right, but this is not the right moment to ask for it. Once this big try happens or not, we will consider your requirement, same as we listen to all our users. Actually there are much more users requesting ER instead of FR, and we have already done a commitment with all the users that have donated and are hopefully, like me, to make this a reality.

I kindly ask you to donate some little money for this ER effort, and once it is done and over, I promise that I will attend your requirements. In order to ask for something, its very nice to give something in advance. Thank you.

Help us and be sure that we will help you too

[reinaldocrespo]

Antonio;

Totally understand. Again, I commend all of you on the effort to include a visual report engine. Better have something than nothing.

I was an ER user myself. I purchased ER from Timm. I later purchased FR from Sergey and now also from that other harbour company that spawned out of fwh. BTW- I only purchased it from them to help fund the effort after Sergey was forever and sadly lost. You may say that I've paid for ER once and twice for FR. I don't think I make a good candidate to revert from FR to ER. However, I will make a contribution for the benefit of all others.

Reinaldo.

[TimStone]

Reinaldo,

I would suggest you re-read my post. It did not contradict your original comments, but rather showed that FWH is constantly evolving to better support all of our individual needs.

I also pointed out that some developers simply cannot afford to purchase many libraries, so anything that can be included in FWH is very helpful.

I personally do not ( currently ) use any of the report designers. My printed output is far too specific so I write all of the code manually. I have done this for many years. I would include the Easy Report into my code for my clients to design supplemental reports if they wish, just like I provided them with a file editor. For that reason I endorsed the project. I've never even looked at Fast Report.

My projects are doing well in 32 bit mode. Until we see commonly sold 128 bit computers / OSs, I have no reason to focus on 64 bit. Thus, that is not an issue for my applications. In fact, even Microsoft, with all their resources, suggests using the 32bit versions of Office in most cases.

Tim

[Biel EA6DD]

Reinaldo +1
I fully agree with Reinaldo.

[Otto]

I use both designers.

From my point of view for cash register, billing, invoicing or accounting software EasyReport is more productive.
EasyReport was developed for a commercial billing system and for such software ER works perfectly.

It is easy to get a consistent look-and-feel and easier management.
In the reportxxx.vrd file which you can handle like an ini file you define
[FONTS], [Colors], [Infos] like Company, etc.
and common parameters like
TopMargin=10
LeftMargin=10
PaperSize=9
PaperWidth=0
PaperHeight=0

If you once have designed a nice setup you can copy these parts to every of your reports and
you don’t have to care about these things again.

Same with header and footer of the reports.
There is an [Areas] entry.
Here you link in the printarea-files.

I have one footer-file for most of my reports.
If I change the linked file the changes are valid for all my reports This is productivity for me.

If end users want special reports they always use EXCEL and we have simply to provide an EXCEL file.
So it does not matter which designer you use.

Programing special lines in ER is much more flexible as you program it in FW/harbour.

You have the whole Fivewin/harbor power:

For e.g.

Printing a costumer customer directory:

If costomer = “Company”

Printarea 1
Here I have all designed for company data
else
Printarea2
Here all for personal data.
endif

Passing parameters in ER is easy . You can use the data directly.

Best regards,
Otto