ExportToExcel Routine

[Rob Kolanko]

Bruce,
I am not sure if the upgrade to NT8.60 or the addition of xfiles to an application caused the ExportToExcel routine to be generated for all NetWeb Browses, regardless if the browse is going to be used to create an excel file. In some of my browses, the value displayed is a local variable in the column's value routine. Thus compile errors are created because the value for the excel cell is a unknown variable in the ExporToExcel routine. To correct the problem, I have used the embeds in the ExportToExcel routine to omit the routine's code.
Since the code for this feature is not trivial and those that use this feature will not need it for every browse, could the generation of the ExportToExcel routine code be an option on the NetWeb Browse template? Or is there some other way to suppress this code generation.
Thanks,
Rob

[Bruce]

You can turn it off globally, or per procedure.

globally:
WebServer, Settings, Defaults, Browse, "Include Export button on browses".

locally:
Browse, Settings, Form tab, Export button tab, "Include Export Button".

cheers
Bruce

[Rob Kolanko]

Bruce,
These settings are not preventing the ExportToExcel routine from being generated. My tests with example apps show that once the xfiles global extension is added the application, the ExportToExcel routine is generated for every NetWeb Browse. The default global setting has the "Include Export button on browses" as unchecked, thus by default the  ExportToExcel routine should not be generated for every browse. Also changing the browse's local setting of "Include Export Button" to No, the ExportToExcel routine is still generated.
Please check your template logic or explain if this is the proper operation.
Thanks
Rob Kolanko

[Bruce]

Hi Rob,

I know we spoke about this in UserGroup #80, and I agreed the code should likely not be there, but I've had a think about it and I'm somewhat conflicted.

Yes, I get that you've been using a technique that is likely not a bad technique, but which is not ideal for this situation. And leaving the code in means you need to move your variable declarations elsewhere. Plus, I'm guessing, perhaps some code needs to move elsewhere as well.

Rather than just suppress the Export routine for now, I think it would be better to understand your setup, and adjust the routine so that ideally it either supports your current approach, or determines a new approach which would become a "best practice".

I'm not keen to just suppress the Export routine because it'll make it that much harder for you later on when you want to turn the Export button on - plus of course others who are doing things in a similar way. I think in the long run it would be better to take a look at this and see if an alternative approach is perhaps better.

So first thing I guess is to get an example of your current technique. Could you adapt any of the shipping examples to show what you are doing, and the error it causes?

Thanks
Bruce

[Rob Kolanko]

Hi Bruce,
To answer your question, occasionally I have  the data fields displayed in the browse that are derived in the field's value routine and the local variable is displayed in the column. To me, good coding practice would be to declare the variables used to calculate the column's value with the value routine, since these variables are not used elsewhere. I could simply declare the variable in the NetWebBrowse procedure and the ExportToExcel procedure will pick it up to compile, however will the variable have the correct value? I do not know if the field value routine is called by ExportToExcel routine when the column value is added to the excel file. It should be.

On the other topic on whether if the ExportToExcel routine should be included in every browse. Right now, I guess that I have created over 75 browses and maybe two of them could be a candidate for export to excel. And should I wish to use the feature, I would do what is necessary to validate that the results are correct. The documentation should describe where the values for the excel are generated.  I can see no reason to have the template generate code that will not be used, when the option exists to tell the template not to generate the code?

Thanks Rob.

[Bruce]

Hi Rob,

(For reference to others, this was discussed at some length in Webinar #81
http://www.capesoft.com/accessories/NetTalkUserGroup.htm )

After our discussion I've reviewed the code. there is a complication not raised in the webinar.

At least for the short term I've disabled it (8.63) generating the Excel specific code if the Export button on the Browse is set to "no".

Unfortunately I cannot suppress the code if the setting is "default" because the "default" is set as a property of the class - the "WebServer" setting is not in scope at that point during generate time. (This is common to many properties which are effectively run-time-settable.)

So unfortunately you'll have to manually disable it on your affected procedures.

Cheers
Bruce