CSV2XL
#26107
31 Jan 18 01:55 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
Out of curiosity after reading Jorges post in  XTREE: export CSV I thought i'll finally try out CSV2XL as I know some customer will find this useful as a lot of users use the export from XTree into CSV. What step are needed to set it up under ATE? I've already took a quick look at the help here. I added SBR=XTREE_EXPCSV2XL to the Linux/Ashell miame.ini but nothing, so I added it to the ATE miame.ini and then got the Export(XLS) option ..when I select it a dialog pops-up saying Outputting xtree-0.xls and thats it (i have hit cancel twice to abort) :rolleyes: I have CSV2XL.SBX 2.1(217) in BAS: on the Linux/Ashell (and also in the ATE BAS: ppn)
Last edited by Ty Griffin; 16 Aug 19 07:15 PM.
|
|
|
Re: CSV2XL
#26108
31 Jan 18 10:30 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
Member
Joined: Jun 2001
Posts: 11,794 |
Hmmm... It seemed to "just work" for me (if you can believe that). I suspect the problem is in the CSV2XL.INI file, which needs some options set up. If that doesn't clear it up, then step 2 would be to set the Debug mode on ATE (from the Debug Message Window properties) and you'll get a lot of traces which should provide some clues. Note that the server side has nothing to do with it - this would purely be a client-side operation.
|
|
|
Re: CSV2XL
#26109
31 Jan 18 11:14 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
I believe it, I did setup a CSV2XL.INI on the Linux/Ashell side from the documentation (same server you VPN’ed to last week) or should that also be transferred to the ATE client before hand?
|
|
|
Re: CSV2XL
#26110
31 Jan 18 12:06 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
Member
Joined: Jun 2001
Posts: 11,794 |
Yes, it needs to be on the ATE side. Since by the time you invoke the Export option, XTREE is running fully on the client side, nothing on the server has any bearing on the process. Perhaps it would be nice if there was some kind of automatic transfer mechanism so as to allow the SBX and INI to be installed just once on the server. But since XTREE in/out/in performance (i.e. minimizing the round-trip latency) is fairly important in many applications, we'd have to find a way to limit the overhead of the automatic transfer so that it didn't happen on every call. I guess another possibility would be for ATE to independently request a file transfer from the server if the files weren't present. That would limit the overhead to only when it was actually needed, but I'm not sure ATE knows where the server's BAS: directory is. (That might require that the app, or an updated version of A-Shell/server, send an AG_SETENV command telling ATE where the server's BAS: directory is.) Short of that, probably the best approach is to just add CSV2XL.SBX/INI to your initial ATSYNC startup command (presuming you have one). (And I should probably admit that when I was implementing it, I was probably thinking too much of the pure A-Shell/Windows environment. There wouldn't be any point in the search path for the different INI files in the ATE environment.)
|
|
|
Re: CSV2XL
#26111
31 Jan 18 12:34 PM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
OK, thanks I’ll have a play tomorrow and agree sync any files to the local PC at login.
|
|
|
Re: CSV2XL
#26112
01 Feb 18 02:19 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
Looks like 'DYNLIB' is the culprit.. I did a test under Ashell/Windows and the XTree (Export XLS) worked and opened Excel with a converted XTree, Neat.. I then turned debugging on and tried under Ashell/Linux using ATE and got: DYNLIB: unable to load: libxl Fn'MinAshVer(6,3,0,0,0): ash: 6,5,1626,3 ate: 6,5,1625,1 = 2162603
Fn'LibXL'Load(libxl, convention=2, stack=8192)...
DLF flags converted from 421 to 221421
366 08:03:55 <TELNET:CSV2XL:1871> DYNLIB: unable to load: libxl
367 08:03:55 <TELNET:CSV2XL:1871> Dynlib error: status=-65537, syserr=0, setting Basic error: 65
368 08:03:55 <TELNET:CSV2XL:1871> Trapped Basic Error #65 (External library error ) at location counter 1871
369 08:03:55 <TELNET:CSV2XL:1871> Call stack trace, from program TELNET :
370 08:03:55 <TELNET:CSV2XL:1871>
From loc 3956, Call Proc() @3e87
371 08:03:55 <TELNET:CSV2XL:1871>
From loc 71d7, Func() @15c9
372 08:03:55 <TELNET:CSV2XL:71d6> Trapped Basic Error #65 (External library error ) at location counter 71D6
373 08:03:55 <TELNET:CSV2XL:71d6> Call stack trace, from program TELNET :
374 08:03:55 <TELNET:CSV2XL:71d6>
From loc 3956, Call Proc() @3e87 I think I now need a hint to where ATE is looking for DYNLIB? etc.. :rolleyes:
|
|
|
Re: CSV2XL
#26113
01 Feb 18 10:37 AM
|
Joined: Nov 2006
Posts: 2,223
Stephen Funkhouser
Member
|
Member
Joined: Nov 2006
Posts: 2,223 |
I'm guessing you don't have a libxl.dll in your %ATE%\bin directory
Stephen Funkhouser Diversified Data Solutions
|
|
|
Re: CSV2XL
#26114
01 Feb 18 10:40 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
Member
Joined: Jun 2001
Posts: 11,794 |
Once again, the debug traces come to the rescue! But... It's not DYNLIB you are missing (unlikely, since it's built in to A-Shell 6.4+, at least for Windows and Linux). Instead, it's the library that DYNLIB is trying to load: libxl (i.e. libxl.dll in the Windows case, libxl.so.1 in the Linux case). The library is included in all the standard packages now, but the one exception may be your special ATE install package. I guess we need to rectify that, but you can also just download it directly from our other/axl directory: .../axl/ Drop it in the bin directory. (And for the Linux case, create a symbolic link libxl.so.1 pointing to it.) Note that for the XTREE export via ATE, the Linux version is irrelevant. But you could also use CSV2XL as a regular print filter on the Linux side. (Typically in that case you would configure the INI options transfer the resulting XLS file to the client and display it.)
|
|
|
Re: CSV2XL
#26115
01 Feb 18 10:41 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
Member
Joined: Jun 2001
Posts: 11,794 |
(I see Stephen beat me to it, as well as putting it much more succinctly!)
|
|
|
Re: CSV2XL
#26116
01 Feb 18 12:06 PM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
Thanks Stephen, thanks Jack ...don’t think I would of come to that conclusion of libxl being missing - more fun for me to try in the morning .....
|
|
|
Re: CSV2XL
#26117
02 Feb 18 04:50 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
I placed this libxl.dll into the %ATE%\bin directory and tried again, and: Ek, This time Ashell crashed with a Windows 'Ashell has stopped working. screen shot So after scratching my head for a while I decided to visit the coffee machine of inspiration, what may of worked! as on my returned I thought as my Windows/Ashell version works I'll start to compare the BIN folders of ATE with the Ashell/Windows. I noticed the Ashell/Windows version of LIBXL.DLL was 3.6.5.0 older than the one I downloaded from your link. Version Screen Shot of 3.7.2.0. So hey its a long shot but copied this version into my %ATE%\bin directory and to my surprise then it Worked! Next, for fun I remote-desktop to a Customer's PC who we do a lot of work for and patched his ATE, This also worked to his delight and it created a nice Excel document. But I forgot it needed to be licensed and he got "Created by LibXL trial version. Please buy the LibXL full version for removing this message" But more of an issue 'XTree crashed scrolling up the screen' (what I can kind of emulate each time) and wondering if they need their UNIX/Ashell binary update from 6.3.1536.0 to the latest of 6.5.1627.0. :rolleyes: But we are getting closer.... Back tracking a bit but if its any help here is a tail snippet from my debugged enabled 'Ashell has stopped working" ashlog.log, while running the 3.7.2.0 version: UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Link]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Link]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Status]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Status]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Hold]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Hold]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Value]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Value]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Source]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Source]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Part Desp]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Part Desp]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Int Ref]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7163> xcall STRTOK,B2[5],S212[Order],S1[,],S7500[Int Ref]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7176> xcall TRIM,S7500[Confirmed P/Orders]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:15ed> xcall AUI,S11[ENVIRONMENT],F[2],B4[0]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:1871> xcall DYNLIB,X84,S30[libxl],B2[2],B4[8192]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:1961> xcall DYNLIB,X84,S64[xlCreateBookCW()I],B4[0]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:19f9> xcall AUI,S11[ENVIRONMENT],F[2],B4[0]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:1b68> xcall DYNLIB,X84,S64[xlBookSetKeyW(IWW)v],B4[84272168],S100[*],S100[*]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7291> xcall MIAMEX,F[93],S30[],S16[],B2[0],S52[],S34[],B2[0],B2[0],B2[0],S100[],B2[0],S12[],S12[],S100[]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:1b68> xcall DYNLIB,X84,S64[xlBookSetKeyW(IWW)v],B4[84272168],S100[Jack McGregor],S100[windows-20272d0201cfe6066bb8696eacrdfau4]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:7478> xcall MIAMEX,F[118],B2[60000],F[1],F[0]
02-Feb-18 08:37:06 [DESKTOP-UIHHU56:01-0]<TELNET:CSV2XL:1e76> xcall DYNLIB,X84,S64[xlBookAddSheetW(IWI)I],B4[84272168],S100[Data],B4[0],B4[0]
|
|
|
Re: CSV2XL
#26118
02 Feb 18 10:43 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
Member
Joined: Jun 2001
Posts: 11,794 |
Hmmm...
So you're saying that the older libxl.dll works, but not the newer one? That's odd, because the newer one has been included in the standard 6.4 A-Shell/Windows and ATE install packages for quite a while now (maybe a year).
The issue might be related to the licensing snafu, and that might be the connection with the server-side version (which otherwise should have no effect on the client-side XTREE-to-XLS operation). (That is, the server typically provides the license to the client.)
Initially, we're going to send you a license update for your in-house Linux server, so we can verify that it resolves the crashing problem. If so, then we'll work out what to do about customer sites. (There are multiple ways to go about the licensing but I need to review them with Ty before clarifying them here.)
|
|
|
Re: CSV2XL
#26119
02 Feb 18 11:18 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
OP
Member
|
OP
Member
Joined: Sep 2003
Posts: 4,158 |
Your correct in saying the "older libxl.dll works, but not the newer one, and so far its been working fine today (only several testes) on our in-house Linux server.
On the customer server side of things maybe I should first update their Ashell/Linux to see if that irons their issues out..
|
|
|
Re: CSV2XL
#26120
17 Sep 18 01:30 PM
|
Joined: Jun 2001
Posts: 3,406
Jorge Tavares - UmZero
Member
|
Member
Joined: Jun 2001
Posts: 3,406 |
Hi, Would it be possible to have an Export to XLSX in the XTREE context menu? Maybe the only difference would be to just rename the file extension but have to do it manually is not handy and I have one circumstance where it must be in that format. Obviously that A-Shell could determine what version of Excel is on the computer and decide but, sometimes that decision is not taken for the local environment, that's why I still keep all the export options available. Once I'm here, would it be reasonable to compress the XTREE options defined in MIAME file in one item in the context menu with a submenu? Thanks PS: Low priority here
Jorge Tavares
UmZero - SoftwareHouse Brasil/Portugal
|
|
|
Re: CSV2XL
#26121
17 Sep 18 02:03 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
Member
Joined: Jun 2001
Posts: 11,794 |
The main obstacle here is whether CSV2XL is capable of generating a satisfactory XLSX format output. (I know it's just a matter of setting OutputFormat=XLSX in the CSV2XL.INI, but there have been a number of issues with the LIBXL support for XLXS format that have led me to shy away from it.) Have you tried it? If it works ok for you, then I guess I see no major problem in revising the context menu and INI options to make it easier for the user to just choose.
|
|
|
Re: CSV2XL
#26122
17 Sep 18 04:03 PM
|
Joined: Jun 2001
Posts: 3,406
Jorge Tavares - UmZero
Member
|
Member
Joined: Jun 2001
Posts: 3,406 |
Apologize, I completely forgot about that INI file. Changing the output to XLSX it does work besides complaining and discarding some useless data, it's not completely elegant but considering that in this particular case I will not even open the generated file, it will be an hidden problem so, for me, by now I'm fine with this solution. I have to check the documentation about how to handle the options in the INI file but, I guess that will not be an issue.
Thanks for the tip.
Jorge Tavares
UmZero - SoftwareHouse Brasil/Portugal
|
|
|
|
|