Win10 - year old project
Checking code with Ctrl-K and building an executable (Ctrl-B) works fine.
Running in debugmode doesn’t. I get this messagebox. Does anybopdy know what possibly causes this issue when I try to run in debugmode (Ctrl-R) ? B.t.w. I did reinstall Xojo and no third-party plugins are used. But still …
B.t.w. 2: pressing the OK button twice makes the program running in debugmode. Think something is missing.
B.t.w. 3: running another project works fine.
Looks like it’s missing the MD5 function somewhere, maybe you can try an find it in your project “MD5” and comment it away?
This happens to me sometimes. I don’t know what causes it, but usually I have to reboot the whole computer to make it go away.
You can see errors like this if your project is stored on a network share, Dropbox folder, or other shared directory. That’s the only time I see these.
Quite strange. I went back to the version I saved an our before this one (sourcecontrol) and noticed that version was working as aspected. Back to the last working version, I renamed the last added method and I could run it in debugmode again. Then I renamed it back to it’s original name and it kept working fine. Strange. Btw xojo 4.1 on Win10. And yes, the project stored on a networkdrive.
Could it be you keep the project unused for a long period?
Possibly there was something wrong in the project (project corruption happens sometimes), a glitch for which the current Xojo version is more sensible. Then, renaming the method (i.e. just “saving” the project) resolved the corruption (as things got rewritten).
Yeah, don’t do that. You’re just asking to shoot yourself in the foot.
Thanks for the hint. Will copy the project tot a local working directory from now on.
@Arnaud_N his is not the case. It’s just the networkdrive
I’m glad it’s practical to you. Once you start having several projects, copying them back and forth between a NAS and your computer is hardly manageable (unless you keep old copies everywhere around and know which ones are archives) and you’ll still go back to store them only on the NAS (which has then other issues, but a NAS is made to centralise things, so that’s valuable).
Yes, but not for Dev Stuff. For this it’s recommended to use a Version Control System. If it’s not just a Drive, maybe one can host it’s own VCS on the NAS.
Well, for guys like me who will never be able to understand those systems (heck, it always takes me 2 minutes to find a link for downloading anything (app, code) when someone holds an app there), the next option to centralise documents is still a NAS.
This is nothing new, and not just a Xojo problem. Using network shares directly has been fraught with problems for a very long time, and version control systems are the most appropriate storage medium for source code. I understand they can be hard to get a handle on, but in the end they are very much worth it.
Whether you choose to setup a git server on your NAS (which I have for some projects) or a private GitHub repo (which I have for other projects), it’s worth the time investment to learn Git. There are many excellent tutorials and even online courses to help out in this regard, and a number of good Git clients that simplify it. I currently use Fork (after recommendation from @Tim_Parnell), but there are many others that will do even more for you.
Or create a free GitHub Account and free private Repos and use one of the many free Linux/macOS/Windows Clients to Push/Pull changes in projects.
Yes, you can do a lot with it, but just being safe and push/push changes is not rocket science. 
Certainly wasn’t my intention to suggest that one need to spend any money on Git, just sharing a client that works well for me.
I use Cornerstone on my Mac which uses subversion internally. It suffices for my needs. I did look at GitHub but could find no documentation there even to tell me what it is.
I found it easiest to think of it as the next step in the evolution of Subversion (though there are many differences). I used SVN for years and didn’t realize how annoyed I was with it until I finally plunged in to Git.
GitHub is a cloud service (free for both public and private repositories) for storing and managing your source code repositories. There are some really good tutorials for getting started, and a quick Google search got me to this one, which uses CLI, but there are others that walk you through the use of specific Git clients.
It’s easy to feel overwhelmed with Git (and, indeed, any version control solution) when you first start, but just focus on push/pull functionality for now. If you’re a one-person team, you may not immediately need functionality like merging, forking, etc. and can learn those when you’re more comfortable.
To describe the Startup Process as simple as i can, i would write the following:
Do this, starting at 3., on any additional machines you like to work on with your Project(s). All the other stuff like Merging, Rebasing and so on is rarely needed if you work alone on your Projects.
In other words, NAS are just nasty and unreliable things?
