Now, on the more serious side. Is the app itself 32-bit despite the OS being 64-bit? if so, you need the 32-bit libraries.
@Roman V The Xojo DLL's are where they always were :-) inside APPNAME Libs folder, next to the executable
The 64bit DLLs don't go there, and neither do the runtime support libs if you include them.
(likely doesn't apply to you, just noting it for future searchers)
Also, try howling at the moon first. :P
I tried so many things now I don't know EXACTLY what I did to make it work... But I suspect, copying the 32 bit windows runtime files next to the app made it work. (something I didn't try before)
Thanks folks for the support.
PS : I DID howl at the moon.....
I am not exactly sure what it means to "copy 32 bit runtime files" next to the application means. But I have a friend (in Canada while I am down here in the States) to whom I sent one of my programs and he gets a "failed to locate framwork dll" error message and cannot run the program.
He is not a sophisticated computer user. He uses Windows (Windows 10). I really only know the Mac universe. I have no easy access to a Windows computer.
I have no "commercial" interest in distributing my programs, but informal distribution has become more complicated. I can no longer just send a zip file with my program to my friend's gmail account because gmail detects the executable within the zip file and for security reasons squashes it. So I zip the file and send it to my Dropbox or OneDrive and send him the link and have him do the download.
When I zip the Windows stuff, I am zipping a folder with assumes the name of the program (in my case ListTA). Within that folder there is the executable file (ListTA.exe) and two folders (ListTA Libs and ListTA Resources). I assumed that the recipient would simply unzip the file and end up with this folder (ListTA) and be able to run the program from that location without difficulty.
I have no problem with the Mac compiled program (which of course just appears as a single file)
But he does have difficulty and I am not sure what he or I should be doing to make it work.
are links to the file in question should anyone in the Windows world have the idle time to play with this and perhaps offer me advice as to what is going wrong with this "distribution". Could he or Windows be taking the exe file out of the folder and moving it elsewhere and therefore making it not work? Or is there some other obvious "issue"? And where would these "32 bit runtime files" be lurking if that is part of the problem?
The program itself is "non-threatening". Just a program to access Terminologia Anatomica medical terminology.
@RobertLivingston should anyone in the Windows world have the idle time to play with this and perhaps offer me advice as to what is going wrong with this "distribution"
I'm trying to replicate the issue here to see if I can figure out why its happening.
I just installed a fresh VM of windows 10 from here and ran your program from the dropbox link.
The application is maxing out the CPU but not showing me anything, I assume that isn't the feature set of the app ;)
I then tried the link from onedrive and it did the same thing.
If you are building for windows from the mac then I really can advise as I've never used this feature, I always build for windows in windows.
Just let me install the Windows Runtime Installer from the xojo extras folder and see if that kicks it into action, nope, that didn't make a difference.
It might be worth putting in a bug ticket for that project, if your code is ok and its not just stuck in a loop somewhere I'd expect it to at least show the interface or crash if it wasn't going to run.
Not much of a help I'm afraid, not even two steps forward and one step back.
I'm just going to fire up my old mac laptop and have a play around making builds to see what happens, I'll let you know if I find anything.
Xojo 2017 v3
My friend has "Windows Defender" that tells him that the program is from an unknown source. But that is it.
This is the link to the Mac version
This is a link to the PC version with Include Windows Runtime as per Tanner Lee
Hmm odd, I can't get it to run on windows 10 or windows 8.1, it just hangs and maxes out the CPU :( It runs ok on my mac.
Would you be ok sending me a zip of the source (in a private PM) so I can run it in the IDE and see what the problem is?
Either that or put it into a private ticket on the feedback system so Xojo can take a look.
All I can suggest really, without being able to replicate the problem :(
Julian: Here is the actual Xojo program itself. I am not concerned about my code being "not private" for this project. Thanks for the time you have put into this so far. I hope it is not something "stupid" that I did.
Here is the binary version
* * * *
Here is the Text version of the program (if needed for Windows folks)
Hmm Xojo in windows hangs on this line:
axOneLine = xInfo.Split(ConstantCR_Tab.CR )
There's something in the data that Xojo doesn't like, so much so that I tried to browse the data in the IDE and it hung in a similar fashion to your app.
It might be worth putting this into a feedback ticket to ask Xojo to look at it.
It might be possible to break the data in chunks and test each chunk to narrow down what part of the data is causing the hitch, or it might just be the size of it, I don't know.
I can't really help with the dll failure issue if I can't run the project :(
Sorry Robert, I'm a bit stuck.
I don't think the dll issue will be something you did per se, I was just interested as it was a reproducible issue that I would have been interested in finding the cause of.
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.
You're welcome Robert, I'm just sorry we didn't get to the bottom of it.
Its a tidy little app Robert, I think you have just found a bug.
I got the gist of how it was working when I was tracking down the problem :) 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).
I'd suggest putting that const, DecodeBase64, DefineEncoding and Split into a separate small project and posting a feedback bug report on it for the windows platform saying the content breaks the split and also breaks the IDE when you try to browse the contents of the variable with it in.
Just remember to mark it as private if you want to keep the source material safe, oh you can remove all those dropbox files now if you want.