Switch for autoupdate

[lscheffler]

📝 Provide a description of the new feature

Please add an switch to the parameters. When running the auto update via .. WITH n, add an additional switch that allows to stop the process.

I run several computers. The configuration is similar, but stuff like Thor will not update if the computer is off. Then I need VFP for something urgent, and start the computer nearby. And every time Thor starts this slow CFU and crawling through any never changing project with this very slow download and unzip process. (Aside this is using my mobile data volume for nothing) I like to have a simple Yes / No messagebox (with a timeout) so I can postpone CFU.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.

[Jimrnelson]

@lscheffler

This can be achieved without any changes to Thor. There are a few alternatives:

[1] Call RunThor without any parameters (or a very large value) to skip automatic CFU entirely, and run it manually from the Thor menu only when desired:

Do RunThor
Do RunThor with 100000

[2] You can all RunThor with a parameter based on a call to MessageBox:

Do RunThor with Iif(MessageBox('Run CFU?', 3 + 256) = 6, 1, 0)

[3] You can modify (and possibly rename) RunThor to add the desired MessageBox where you see fit. It's a straightforward little program.

[lscheffler]

I'm sorry, but this is insulting.
Am I an idiot that you say I should set CFU to 273 years or call a Messagebox on every start of VFP? 10times the day?
Or is it not clear that I do not like to fiddle with parts of Thor myself? That I'm able to do so does not mean I like to do, or I would not raise the issue at all. It's a real concern to me.

Thank you for your help.

[Jimrnelson]

@lscheffler

To make this as simple as possible for you, follow these steps:

[1] Call RunThor without a parameter, so that CFU is not run automatically.

  Do RunThor

[2] When the time comes when you want to run CFU, run "Check For Updates" from the Thor menu pad:

[rschummer]

@lscheffler

Jim provided several ways to provide you exactly what you asked for without changing Thor at all. This is not insulting, it is awesome. It shows the flexibility of Thor and all it requires is a small change to the code you have to have to run Thor in the VFP IDE. His second suggestion gives you the MessageBox you requested upon startup. The third and even his fourth suggestions satisfy the requirement to run the CFU the way you want to run it without prompting.

For me, I have Thor check for updates once a week. If I need something sooner, I manually run the CFU process.

Also, I believe when I have run into this situation where CFU is plugging through all the projects and I need access to VFP more immediately, I just run a second copy of VFP while the first one is getting Thor going. It seems that Thor CFU updates the next date before it goes on the way to get the list of projects. The second instance of VFP should start faster.

Rick

[lscheffler]

@rick
If you think the maintainer telling somebody to set update frequency to hundreds of years is awesome, well, that is a POV I will not join. This is what one is calling rude support. Next will be the question if the comp is turned on.
Aside that (knowing a bit of Thor) the whole idea to use RunThor without running CFU periodically at startup is wrong. One can run Thor without this startup program and run CFU manually - with the the problems that are solved by RunThor. There was a reason for this peace of code.

My CFU process is like yours - only it's not only one comp. The main comp is no problem. It's more client side work, where I open up a comp not used for weeks to look into something. And then this CFU starts. Unstoppable.

To your idea to start VFP twice,

• In general I can not recommend this
  • The risk that Thor is in the middle of updating itself and will fail is high, when the second instance locks the Thor parts or it's loaded modules. It's not a high frequency of updates, but repairing Thor and it's modules is a such a pain, I rather waste my time waiting. If it fails you might work for several days getting Thor to work again. All the little settings gone.
• For me this this will not work.
  • The PJX's are loaded in front of RunThor from FoxUsewr by VFP, so the second instance will be without the projects. Can't work there.

Thor and the Thor installation are in no way good to maintain. All my attempts to participate failed, and I will not retry above raising issues. And I'm against forking, this is not good.

Anyway, if it's just such simple code as the maintainer wrote, I can not see why he can not do it. ¯\(ツ)/¯

[rschummer]

@lscheffler

I think you should reread what I posted, Lutz. I did not agree that setting the update frequency was the best of the options from Jim. In fact, this was the least desired option of the four he gave you and one I bypassed too (even though it also works as a solution). I noted that he solved your specific request for a MessageBox prompt without having to change the base code.

Calling Jim's near instantaneous response (same day, within hours on a workday) on a volunteer open-source project rude is unnecessary. Open discussion and back and forth dialog are the exact appropriate approaches. This kind of back and forth where ideas are exchanged have worked on VFPX for a long time.

Rick

[DanielCarlos231]

@lscheffler
Since Thor is FREE AND OPEN SOURCE you have always the options of unistalling it, and make your own version and add your own functionalites.
The ones who developed already have the patience to still give support which he is not obligated at all and do it for free and you still think he has the obligation to add functionalities you can solve on your own, without having to make any changes in the main source code.
Bad support?? How about bad gratitude of your part

[lscheffler]

@DanielCarlos231 Not bad support I wrote One would call this rude support. Only this is not a support request at all.
This is not a report of a failure I need to solve, this is a suggestion to make the thing better. I just brought up an idea, a request for a feature.
I like to to tell you in all kindness, please understand the difference between a feature request, an error report and a support question.
The maintainer simply gave an support answer to a request of a feature. And this answer is, by his knowledge of my understanding of Thor, rude, insulting. And, since I'm through this with this maintainer several times, I have no other chance then counting it intentionally.
I do not need a .. lecture of .. non-solutions like an all-time messagebox or a CFU frequency into eternity. Or like in #258 (comment) to turn the startup CFU off at all and run CFU interactive. There was a .. reason to allow CFU at startup, and I'm happy to have it. The maintainer should know this - we worked a way on exactly this program and issues with it. Only sometimes it would be good to postpone it.

The code to enter, even with a parameter, is simple enough. Surely it's running on my comp. But, as I posted above, I do not participate maintaining this project above raising issues. I have reasons, but those do not belong here. Anyway, I presume that the maintainer have profound knowledge of this situation.

---

Off topic. I welcome you to uninstall / install Thor. Much fun. It's (And to make that clear, there is nobody to blame for this, it is just grown that way by many developers participation) a very painful process to remove Thor and its module clean from your comp. Not just removing the Thor folder, this is not nearly enough. Reinstall the OS from scratch, it's faster. Also there is no way to store / restore all settings. I'm through this, because I tried to participate maintaining Thor, and failed.

---

@rschummer Folks, I stop this waste of time. It's useless me talking to Jim is less valubale then talking to the see, I must finally accept this. Please just remember me next time try this.
I beg everybody for a pardon for the retry. I should know better.

[lscheffler]

Reopened, the thing seems not that simple. The counter must move or the system will be out of sync.