ExportXlsx 1.8 and CopyToXlsx 1.9.1 4

[vgulielmus]

Improved versions of class (ExportXlsx 1.8) and procedure (CopyToXlsx 1.9.1) that exports data from VFP into Excel 2007+ workbooks
The links from my blog (first link) contains some explanations

CopyToXlsx 2.9.1
direct link
CopyToXlsx 2.9.1

ExportXlsx 1.8
direct link
ExportXlsx 1.8

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Dan Olsson]

This is really amazing - but there is a small bug in CopyToXlsx.
It always leaves 3 temporary cursors opened after execution...

 

[Dan Freeman]

Very timely. I was just going to go looking for this.

 

[dantheinfoman]

Very extremely cool. I love the VFPX.codeplex projects!! I can't figure out how to open an XLSX like you can when

import from (myfile) TYPE XLS

, but I love all the hard work and we all appreciate it guys!!

Dan

 

[Koen Piller]

It always leaves 3 temporary cursors opened after execution...

Hmm,
I was always under the impression that cursors are by definition temporary and are getting disposed off on shutting down vfp or the exe. Am I wrong here?
Regards,
Jockey(2)

 

[Olaf Doschke]

No Jockey, you're not wrong, but only whern the session is closed. Simply imgine calling a function and afterward three cursors are in your datasession, that only were needed in the called function.
It's only a thing of tidy up. It can be useful to have some data still open, it can have negative sideeffecs if you scan a cursor and that's not selected after the function returns.

As drdolittle said, it's a small bug, as these extra cursors in themselves maybe not hurt, unless you have extra and unexepected cursors in code going through all open tables via AUSED() or anything like that. It's about the same thing if a function generates public variables and "pollutes" your memory with something not ordered.

Bye, Olaf.

 

[Mike Lewis]

I'd say that it's always good practice to close a cursor when you have finished with it. Closing a cursor has the effect of deleting it from its temporary location, just like when you close the EXE or the VFP session. Leaving unwanted cursors lying around would probably do no harm, unless you call other functions or methods that happen to use the same cursor names. It's really a question of tidiness.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Olaf,
Mike,

Yes I know but whay does anyone wants to call this a bug????
I mean even if you leave all the cursors open in your application, agree, my mother also always cleans the kitchen after dinner was served, but the cleaning is done by VFP. Would you be able to give me an example why this 'untidiness' would harm your application? Realy this is not an acedemical question, nor one of a wise guy, just would like to know why someone 'dares' to comment on such a brilliant class with a bug, which is, again, to my opinion, not even there?

Jockey(2)

 

[Olaf Doschke]

I'd also call it a small bug, it's not being tidy, it's not being correct with the scoping of things. And while this will not harm on its own, it can influence furhter processings, as I already layed out.

A bug isn't just a bug, when it throws an error.

A book full of punctuation, grammar and spelling errors also "works", it's readable, but wouldn't you also call that buggy?

Bye, Olaf.

 

[Koen Piller]

Olaf,
I see you made a point. However one thing, would you be able to produce a sample where a created cursor, and not deleted after its use will throw a real error?
Thanks,
Regards,
Jockey(2)

 

[Koen Piller]

Hi,

Do you also call the fact that the variable llErr is not declared as local a bug?
According to

https://simple.wikipedia.org/wiki/Software_bug

not.
And not closing the cursors for me also not. I would rather call it sleazy in an otherwise brilliant procedure.

I fear this might come into an endless discussion, difference of opinion.

Regards,

Jockey(2)

 

[Dan Freeman]

Do you also call the fact that the variable llErr is not declared as local a bug?

No, because unless the variable is declared PUBLIC it will default to PRIVATE and will be automatically released at the end of the code that created it. LOCAL only impacts called code, not calling code.

Called generic code that alters state (SET TALK, SET EXACT, etc.), and state includes opened workareas, has a bug.

"The code is completely generic except it changed SET DATE and SET EXACT" is a description of buggy code. Generic code that leaves behind unexplained open cursors is the same thing.

This is not an insult to your code. Please don't take it that way. You just need to finish cleaning up.

I haven't looked at the code yet. What happens if it's called in a loop 200 times? Does it leave behind 600 open cursors?

 

[vgulielmus]

Thank you for the kind words and for the feedback.
I am grateful for all suggestions and for the support seen here, especially when comes from programmers of your caliber.
I also appreciate any future suggestion.

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Olaf Doschke]

Jockey,

Dan has already answered, also I already stated where an additional cursor can influence further processing, assume you do AUSED and process any open cursor in some way, then an unexpected cursor not from you can disrupt your code. Whatever happens in your scope and is not the documented result or behaviour of a module you use is a bug, too.

For example I wrote database interfaces, classes quite like webservices that had methods like getRecipe(id,"crsRecipehead","crsIngredients"), that'll return cursors and then had the configuration option of tidyup .T. or .F., because additionally to the expected result cursors I might leave the underlying tables of the recipes open or close them. If a user of the interface knows he'll pull several recipes out, leaving tables open will make the whole loop faster.

So it can be useful to leave things open, if they are usable for the next call, but you better make that configurable.

This is not strictly about encapsulation, as that is more about the aspects of code separation and separation of concerns, but it tends to go into this regime. If the next call will CREATE CURSOR xyz again, you don't profit from the left open cursor and you also don't save time closing it, at some time it will be closed anyway.

Another simpler reason is, if you ever debugged code and you have more cursors open than the datasession window can show - even resized, then you're at a point where debugging is harder due to a cluttered datasession. A workaround is SELECT aliasname, if you know the alias name you want to browse, but it's easier with a tidy session, isn't it?

Bye, Olaf.

 

[vgulielmus]

Done.
Please download the new versions, either from the attached archive, either from the links that points to my blog.
- temporary tables are closed
- current alias is restored
- improved cleanup

ExportToXlsx 2.0
and
CopyToXlsx 3.0


Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Dan Olsson]

Thanks a lot - the Dropbox links does not work (for me anyway) but engineering does so all is well

 

[Dan Freeman]

This is a happy new year treat!

 

[Koen Piller]

Indeed a gem!
Thanks Vilhelm

Jockey(2)

 

[Olaf Doschke]

I'm very pleased to see this going forward.

Thanks!

Bye, Olaf.

 

[vgulielmus]

Very kind words from all of you.
Thank you very much.

The same changes for the equivalent procedures that generates Word 2007+ respectively PowerPoint 2007+ documents (export to docx and export to pptx)

Please download the new versions, either from the attached archive, either from the links that points to my blog.
On my blog the properties of the classes are explained
CopyToDocx 2.0 (procedure)
ExportToDocx 2.0 (class)
CopyToPptx 2.0 (procedure)
ExportToPptx 2.0 (class)

or directly from the attached link (ExportToXlsx from this archive contains a very minor correction)

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania