Well, Julian, you went far beyond the call of duty. I have just finished watching the Webinar: Cross-Platform Tips and that makes clear my “wishful thinking” about how Xojo would work “magically” across Windows/Mac is not a particularly robust approach. It is more complex than that.
If I am to offer cross-platform versions of my little projects then I am going to have to invest in Windows and setting up testing environments and learning a lot more about Windows than I want. Basically, my niche of programming is non-commercial and addresses small audiences and I find having to do more extra stuff than I would like to offer Windows versions painful. But it is clear watching the video and with my experience here (with what is a fairly small project) that I my wishes and reality are too far apart to be ignored.
To touch on where you were when you found the line that confounded Windows. It was a year and ½ ago that I wrote this code and it is difficult for me to reconstruct my thinking exactly, but all the raw data for the app is contained in a Table that is probably about 5000 records with 7 fields (none of the latter particularly big). So all that text is sizable but not HUGE.
Well, that are many ways that I could handle that data. Options I considered included storing it as a JSON file or an XML file or even just a text file or an SQLite database. Then I came across the idea of storing it as a CONSTANT inside the program itself. To be even more clever, I stored it as a Base64 file.
This was amazed how well it worked! This large text constant was contained within the program itself so that the users did not have to deal with a separate file when they set-up the program. I did not have to worry about distributing this separate file. The data is accessed only at the time of launching the program and placed in a bunch of arrays that are subsequently used for displaying in Listboxes. With this technique, I did not have to deal with opening files. I did not have to deal with users moving files to some other locations by mistake.
The work that I did to create that Table originally was huge. I scanned a book dealt with multiple languages etc. I did not want people to easily just rip it off. Base64 acted as a slight level of security for the data. It would have taken a certain level of sophistication and cleverness to reverse engineer all this.
On Mac, where I tested it, it is flawless as best I could tell. I thought it was genius. Until recently, I did not realize that any PC users that came to my website to grab the program were just going to crash. When this happens with free, niche software from some developer you do not know, most people do not even bother to complain. They just move on. They think that maybe their machine configuration is weird. The software sucks. Whatever. So I do not know how many people were affected. Finally someone bothered to write me and complain.
axOneLine = xInfo.Split(ConstantCR_Tab.CR ) was the second step of processing the CONSTANT (TA_INFO). Initially code runs to take the Base64 constant and convert it into a Text variable. It is a TAB delimited text variable (Fields separated by TABS and Records separated by Carriage Returns). The line where the crash occurs is where the Text variable is being processed into an array which each element containing a Record. Subsequently that array will be processed so that each field in the record can be stored in its own array. Those field arrays are all the program needs for its subsequent data access. They are static. And accessing them is very fast.
I do not know why the crash occurs here in Windows not Mac. We seem to have successfully converted the BASE64 data into a “simple” large text variable without difficulty. I would think it would be clear sailing after that.
axOneLine = xInfo.Split(ConstantCR_Tab.CR) // Turns out that it requires carriage return as the delimiter
The Split function is using as the “splitter” the UTF-8 value for carriage return. Who knows whether the issue relates to this “splitter” in Windows vs Mac. There are differences in the EndOfLine value for the two operating systems but I can’t see why this would matter here. Perhaps the Split function in Windows sputters when dealing with this rather large text file in a way that it does not on Mac. Perhaps the conversion of the Base64 CONSTANT to text was not actually completely successful and the “simple” large text variable which I assume to be healthy as it enters into the xInfo.Split is actually corrupted in some way and this is revealed when the code tries to Split it.
I can see several possibilities. And I can see ways to test them. And I could play with actually using a JSON file or a text file as the basic source rather than some large CONSTANT.
But I would have to buy Windows. Learn about Remote debugging? I know I can legally compile for Windows (in this case unsuccessfully) and I have the Desktop License that covers two computers. I do not know if that means one of them could be a Windows machine and the other a Mac. I currently use my two licenses: one for my Desktop Mac and the other for my portable Mac. I do not know what kind of dance would be possible or legal in terms of removing one of on these from one of these Macs and putting it on some Windows machine (virtual or real) while I was trying to test the code in a Windows environment. Or exactly what Remote debugging means (ie does that mean that I can use my license on my Mac to run Windows code in some virtual environment. Or some Windows machine which is just sitting on my network that need not be virtual. And does it just feel as if I am running the IDE on a different platform indistinguishable from actually having Xojo installed on a Windows machine and working there?
All this seems overwhelming complex as a write this. Just to deal with this one ?little? issue. I have not yet watched the Webinar: Remote Debugging and will do that tomorrow. I own Parallels but have never learned it well enough to feel comfortable and I am using an old Windows version there (not 10)
I have successfully deployed Windows versions of other small apps that I developed on my Mac for use by niche Windows users who have the fortitude to deal with not having a nice Installer and having Mac conventions thrust upon them etc. But this is my first real problem. And this is not some huge complex program. It is just a little utility.
I enjoy coding. I hate dealing with licenses and trying to understand them and their restrictions. And since, for me, this is not recompensed work, the dollars involved would all be out of my pocket never to be seen again.
I thank Julian and Tanner for volunteering their time to trial the code on their Windows machines. At least I can go to my website and remove the Windows version (at least for the time being) and stop abusing the rare Windows user who might stop there to download the program.
I could look into a bit further but I notice you’re storing the data with ids to parent entries etc. so its not just a case of trimming out sections until I find the culprit (if at all).