Hi there.. its been a while so here a very easy question and one I may of missed an obvious existing switch, Does the XTree CSV/XLS export the Total fields? (Mine dont) - I have some calculated totals that the customer wanted to include in the export.
Welcome back! And thanks for the easy question (even if the answer isn't as easy)...
The XTREE export routine does not currently attempt to explicitly export the totals, possibly because it expects the CSV2XL.SBX routine to add totals "when appropriate". The problem here is that CSV2XL's idea of "when appropriate" may not match yours. But it is at least somewhat configurable via the CSV2XL.INI file. Basically you have the option of turning on automatic totals, and if so, then there is a regex mechanism for identifying columns that are numeric but still shouldn't be totaled...
Code
[FORMAT]
TotalsBG=COLOR_GRAY25
;regex pattern applied to col titles to force the column to be treated as text (zip, part #, etc.)
;Example: zip|(part *(no|num|#))|phone
; matches any title containing "zip", "phone", or "part" followed by optional space and then "no","num", or "#"
; matching is case insensitive, not anchored (use ^ and $ for start/end anchoring)
ColTitleTextRegex=zip|(part *(no|num|#))|phone|sku|invno|wo|code|po
[DATA]
;AddTotals: 1=yes (add line and auto-total any numeric col) (default=1)
AddTotals=1
Of course in the ATE environment, it would be the client copy of the CSV2XL.INI, so if you're going to resolve the issue this way, you'll probably have to add BAS:CSV2XL.INI to your list of files being sync'd from the server on startup.
It probably would make sense for XTREE to detect the presence of =SUM totals and force the exported spreadsheet to total those columns (and perhaps make sure the other columns are not totaled). But it might require some analysis to make sure we don't end up with two sets of totals, and/or interfere existing configurations that are working according to some kind of plan.
Thanks for explanation and possibilities and just adding a little more complication to it as the current example even "automatic totals" would not work part of the export as the column contains Yes and No's but the Total at the bottom is a percentage value of Yes's, I was thinking more in line of if XT'XTRCTL.SHOWFOOTER is enabled export how ever it was populated, but as there more thinking and work involved either end dont worry right now and least i got an answer to their question and can go back to the customer with "its not possible as it is right now" may be on in the future. Thanks
Right! (Sorry, I didn't look closely enough at your example or would have noticed that obviously those were not the result of the =SUM mechanism!) Using the SHOWFOOTER flag to determine whether to include it in the export seems like the best approach, but probably needs to be combined with an embedded directive to CSV2XL to stifle automatic totals. Consider it on the to-do list.
It must of rained at some point , so Thanks Jack the Totalling exporting is great in 6.5.1711.0, tested under Ashell/Windows. When you feel its fit to do could we please have an ATE version, The PDFX stuff will still be backward compatible? We still use the PDFX3SA_sm-3.6.0.130.exe install. Thanks!
As for PDFX backwards compatibility, as odd as it may seem, the new A-Shell/ATE is backwards compatible with PDFX3 (aka PDF-XChange 3.0, which is the one you seem to be referencing), but not to PDFX5. Prior versions of A-Shell/ATE are also compatible with PDFX3, but not with PDFX9. The reason why PDFX3 compatibility was able to be retained, but not PDFX5, was that the PDFX3 version uses a completely different interface between the application and driver, consisting of ESC sequences sent to the driver. Starting with PDFX5, the interface was changed to a COM interface, but for whatever reason, the various versions, PDFX5 thru PDFX9, have all used the same COM object, which limits the compatibility to just one version at a time.
On the bright side, the three driver versions (3, 5, 9) can all coexist, so there is no harm in installing the PDFX9 driver for testing purposes. But if you're happy with the PDFX3 driver, you should be able to continue using it across the entire range of A-Shell/ATE versions.
Ah your Rain Channel must be distant cousins to our Sun Channel ???? Thanks for the ATE link and good news on the PDFX front glad we stayed on version 3 now.
