ViewXLS

Stuard, you are very attentive.

I’ve ask Raik to check if this version works on the Pi3, before I announce it. So I hope it does.

There are some minor fixes too. And a little more text in the Help file.

Raik confirmed, 0.22ß works on Pi3+

@ David
Textfiles are interpreted as TSV by ViewXLS. I make a note to add a better check to avoid this behavior for the next version.

If we find XLSX files that will not load, would you like examples sending through? Or are you well aware of things that still need supporting?

Matthew, you can send me the XLSX file, ViewXLS has a problem with. And there will always something, that still needs supporting ;-)

Anton happy to report that ViewXLS and sch2xls work work for me on a Pi3b+, Pinebook and ARMX6. I have have not done extensive testing but ViewXLS read the XLSX files that I had readily available. Great work and many thanks.

!ViewXLS 0.22ß does start up … on OS4.02

With the 32bit CLib I should have said, which is not rmensure’d.

might benefit from linking to StubsG

That would not help in this case as the iconv module is also 32bit.

The error in a 26bit only environment is. “SWI value out of range for module SharedCLibrary”.

*fx0
RISC OS 4.02 (10 Aug 1999)
*help SharedCLibrary
==> Help on keyword SharedCLibrary
Module is: C Library       4.87 (23 Apr 1999)
*

Matthew, you can send me the XLSX file, ViewXLS has a problem with.

Unfortunately I now realise it’s not possible to send you the file because it has personal data in it. I will see if I can edit the file to remove the personal data without the problem going away!

Anton, I could send you a file that doesn’t load at all, if only I knew your e-mail address.

Edit: Suddenly, I realise that I don’t need an e-mail address, of course. The particular file can be downloaded from:
https://drive.google.com/open?id=100DEz509zK-BuCDLwMJy-TOZ9rwpm05Z

Paul, thanks for the sample.
I’ve fixed some issues. You will find the updated version 0.23ß on my homepage.
My e-mail adress is now in the Help file.

Edit: The colours from xlsx files are not represented very well by ViewXLS. These files are converted to xls internally with it fixed palette.

You will find the updated version 0.23ß on my homepage.

Just installed and tested version 0.23B, worked fine on half a dozen .xlsx files I had lying around. Content-wise they were straightforward, no embedded charts or graphs, just data, but the formatting seemed to come across OK.
Well done Anton!

The colours from xlsx files are not represented very well by ViewXLS.

Personally that’s not a problem – viewing the data is the key thing.

EDIT: I’m using a Pi3, RO5.24.

Paul, thanks for the sample.
I’ve fixed some issues. You will find the updated version 0.23ß on my homepage.

I’m sorry to have to report that the new version doesn’t load my file either. This is true on the ArminiX, with RO5.23 as well as on the Virtual Acorn.

When I drag the file on either computer, nothing happens at all. When I double click on it, it generates an error, saying that ViewXLS is already running. When I double click the file while ViewXLS isn’t running, nothing happens as well.

Paul, what shows the ‘Next’ WimpSlot?

Anton, Next shows 4800K. But even when I drag that to the maximum, it doesn’t change a thing.

Paul, raise your problem only with XLSX or with XLS too?

I have try Pauls sample and a XLS from my business on Ti (5.27), MX6 (5.25) and RPCEmu (5.27 and 4.39)… no problems.

Paul, raise your problem only with XLSX or with XLS too?

XLS files are doing fine. Only XLSX files fail to do anything, at least on my computers. Just out of curiosity: do XLS and XLSX files share the same file type? (ba6)

Version 0.23 beta of !ViewXLS fails on VRPC RISC OS 4.39 with an error File ‘System:Modules.SharedCLibrary’ not found. Also !Boot.Resources.System.Modules.CLib is version 5.47 so it is asking for the wrong file name. Should it not have an updated CLib file inside its application directory, rather than rely on finding it in Resources.

do XLS and XLSX files share the same file type? (ba6)

No, look inside !Run

I noticed, for unknown reason, the filetypes in the !Run file are wrong.
In the !Boot file it is correct, so I never noticed it:
Set File$Type_BA6 MSExcel
Set File$Type_A7F MSExcelX

SharedCLibrary: don’t know how to handle this ‘correct’ with VRPC. Checked it with RO 4.39 at my Omega.

On OS4.39 RPCEmu the 32bit ROOL SharedClibrary is in 310.Modules and is RMEnsured in !System.!Run.

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib

As recommended by Castle, a long time ago. It is optional, the first app requiring the 32bit CLib can RMLoad it, as ViewXLS would given the correct filename.

Set File$Type_A7F MSExcelX

That’s it! Great work, everything works fine now!

Should it not have an updated CLib file inside its application directory,

ABSOLUTELY NOT

Softloading a CLib on top of a softload CLib will break everything. Do not do this.

Try to load the one in the system resources (so the first to do so will get it running), and if that’s too old, complain and tell the user to update their system.

[this is one of the things that StubsG was written for, but it’s mostly a historical issue for older machines as the RISC OS 5 images will contain suitably recent versions of the library already built in]

I’ll alter the RMEnsure to require 5.47 (which is the latest version for VRPC) and try again.

That seems to have done the trick.

The shared C Library has always been a horrible mess since Castle released the Iyonix and tried to stop people distributing it.

Is there a wiki page somewhere that suggests the correct RMEnsure things for C applications depending on

• which OS versions it should run on
• whether CallASWI is needed and why (i.e. which SWIs your code contains that need it) and for which OS version
• which CLib version is needed if CC version xx compiling Cyy is used
• which fpe compile option requires which version of FPEmulator

On the other hand, why not RMEnsure UtilityModule 5.24 and leave that legacy stuff for the tinkerers.

Softloading a CLib on top of a softload CLib will break everything. Do not do this.

The correct way is to include with the application a copy of !Boot with an updated Shared C Library in it and ask the user to boot merge it and reboot.

I’ll alter the RMEnsure to require 5.47 (which is the latest version for VRPC) and try again.

Is there any reason not to run the latest CLib 6.03 on VRPC? Or the converse, is there any compelling reason to update from CLib 5.47?