HMGforum.com

NEW ON RELEASE 0.34

- new: error checking for SQL objects.

- new: setQuery( cValue ) for SqlBrowse() object.

- changed: each demo is in its own source file now for easier reading.

Download: http://sourceforge.net/projects/hmgscript/

Enjoy!

Thanks

When new release published, you erase previous ?

Best regards

--

Esgici

esgici wrote: When new release published, you erase previous ?

Yes.

Thanks a lot Roberto. It's nice.

Now, I am working on PHPSQLite the same way.

And the next one is, PDF creation. Once that is over, printing part will also be over.

rathinagiri wrote:Thanks a lot Roberto. It's nice.

Now, I am working on PHPSQLite the same way.

Good idea. SQLITE is being included in many hosting services. From a PHP perspective, the database engine is being executed in the local machine, so SQLITE could eventually do as well as MYSQL does, with the advantage that it is fully free, so there is a great future on it.

rathinagiri wrote: And the next one is, PDF creation. Once that is over, printing part will also be over.

Yes. I've been researching about that.

My first choice was generation on client side, but, the only evolved enough solution is jspdf, but it does not run on all browsers, so, it must be done at server side. I'm using fpdf for other projects and it is doing well. The problem is how to use it from client in an easy way.

Regarding other of my goals (dbf PHP support) I've dropped the idea, since there is no support for indexes, locking, searching, etc., so, it is not viable.

Another idea that I've dropped was to have an unique interface for xBase functions and SQL ones. After thinking about that, I've realized that is better that SQL queries can be written directly as SqlBrowse, SqlQuery and SqlExec allows now.

Exactly the same way of thinking Roberto.

Regarding PDF, yes fpdf is the nice choice. I think we have to collect all data for printing from startdoc() up to enddoc() and once enddoc() is called, a single call from js to php can be made along with all the parameters. What do you think?

rathinagiri wrote:Exactly the same way of thinking Roberto.

Regarding PDF, yes fpdf is the nice choice. I think we have to collect all data for printing from startdoc() up to enddoc() and once enddoc() is called, a single call from js to php can be made along with all the parameters. What do you think?

I've was thinking exactly that!

I absolutely agree.

When printing be finished, will be ready for production apps.

Roberto Lopez wrote:

rathinagiri wrote:Exactly the same way of thinking Roberto.

Regarding PDF, yes fpdf is the nice choice. I think we have to collect all data for printing from startdoc() up to enddoc() and once enddoc() is called, a single call from js to php can be made along with all the parameters. What do you think?

I've was thinking exactly that!

I absolutely agree.

When printing be finished, will be ready for production apps.

But...

Many times, I spent a lot of time thinking prior to start coding and sometimes (only sometimes) it results in a good thing

Regarding printing, I've realized that my first idea is pretty inefficient

In the proposed schema, we need to transfer the data from server to client, create the report in the client and then transfer processed data again to the server to be converted to a PDF, then the PDF is transfered to the client.

So, the data (in different shapes) traveled three times across the network.

This is not a problem for small reports, but for big ones, it will be.

So, my idea now, is to create a report class, like this:

SqlReport ( cQuery , cTitle , cPaperSize )

It will create a PDF file (using fpdf) that will be transfered to the client.

Of course, it can be expanded later to give it the ability to create non-tabular reports, include images, etc.

We will need the Harbour counterpart too, but I'm not sure what PDF library is better and how exactly we could transfer the file to the client using uhttpd server.

It should be something like:

Report ( cTitle , cTable , cOrder , cFilter , aColumns , aTitles , cPaperSize )

Really nice interpretation Roberto.

A common reporting for any table/array to print (like gridprint) can also be created using jspdf thereby avoiding any data transferred unnecessarily.

rathinagiri wrote:Really nice interpretation Roberto.

A common reporting for any table/array to print (like gridprint) can also be created using jspdf thereby avoiding any data transferred unnecessarily.

I agree and I love jspdf, but, as I've said, it does not work with current versions of FF and IE.

There is a workaround to make it work, that consist in a swf component that requires Flash.

The problem is that IE10 on Metro will have only a limited support for Flash, according an official statement on this regard: “only sites that are on the Compatibility View list can play Flash content within Metro style IE.”.

My goal is to assure that HMGSCRIPT will work on all major browsers and platforms (IE FF, Safari, Opera and Chrome) / Windows IOS Linux and Android.

In my particular work experience, I have no control over all the client machines, ie: one of the remote location, uses Windows 7 (IE9) connected to a Windows server (domain controller) configured in such way that the users can't install anything, so, I must make print work in that environment.

Another common situation is that the users occasionally uses a public machine that they can't configure in any way.

So, sadly I must say no to jspdf, at least, until it starts to work on latest versions of IE and FF. I'm talking about the main HMGSCRIPT distribution, but it can be added along contribs, specifying the known compatibility problems.

I'm experimenting now with JS window print method, but (again) it does not work consistently in IE and all other browsers.