jason Posts: 13
25/07/2018
|
Is there a way to run a script that will update all the versions of all the applications rather than me going through each app and click the version button to see if its a new version because at the moment it still believe the old version is installed even though a new version downloaded..
-- GEGeek Tech Toolkit Creator/Developer
|
|
link
|
Gianluca Administrator Posts: 1274
25/07/2018
|
Nope.
The SPS system relies only in itself. So if you download a new package and update an app without outside the SyMenu domain, the SPS system won't be notified about the new version and it will want to download the program again.
Anyway if you are sure about the version you've downloaded and installed, you can create a script that updates all the v.x.y.sps.version files that you find in every SPS program root. It's the native way the SPS system uses to keep track of the downloaded version.
BTW I suggest you not rely to much on the version button because the main executable file version could be different from the program version (think about a launcher file and the related main executable file... all the PAF programs suffer of this imbalance). In some occasions you can find programs that don't carry the version number in the right way, right according the Windows recommendations (for example SUMO, TOR and many others). More, you can find programs that assert to have a certain version (for example 5.31) and carry a different one (5.3.1.0).
Jason it's a real mess, my advise, leave the SPS system in charge and you'll save yourself a bad headache.
|
|
link
|
jason Posts: 13
25/07/2018
|
Thanks for the reply.
-- GEGeek Tech Toolkit Creator/Developer
|
|
link
|
VVV_Easy_Symenu Posts: 159
26/07/2018
|
BTW, Is there some visibility of implementing the "alert on update" with the SPS Apps with "Build in updater" checked (with "0.00.sps.version")?
https://www.ugmfree.it/Forum/messages.aspx?TopicID=627#post2105
|
|
link
|
VVV_Easy_Symenu Posts: 159
01/08/2018
|
I explain the idea better.
Today, the SPS Apps with the "Build in updater" checked by the publisher are installed with "0.00.sps.version" and SyMenu is not able to follow the updates that the publisher continues to make.
For having update the SPS Suite with this kind of apps, the user must remember what are this apps, run its with a internet connection working and with the inner updater checked.
In order to manage all updates with the SyMenu system easily and with a minimum programming work for Gian ;-) , I could suggest: 1) Write in the text of the VersionFile the installed app version too in all the cases, for instance:
- Subtitle_Edit (NO build in updater) -> VersionFile: "3.5.6.0.sps.version" containing the text "3.5.6.0.sps.version"
- SUMo_Portable (YES Build in updater) -> VersionFile: "0.00.sps.version" containing the text "5.7.1.sps.version"
2) Add a new option, may be "SyMenu update priority" or "Alert always in update" or "Overwrite build in update" that sets the following behaviour:- NOT checked (actual system) SyMenu looks the VersionFile name for update disposable alert (nothing to do if "0.00.sps.version" name).
- YES checked (proposed system) SyMenu looks the VersionFile text content for update alert (If the file is empty it alerts to implement backward compatibility)
What do you think?
edited by VVV_Easy_Symenu on 01/08/2018
|
|
link
|
Gianluca Administrator Posts: 1274
01/08/2018
|
It's a good solution. It's easy to implement, it preserves the updating logic currently available, it leaves room for the advanced users to decide what's the best update strategy for them.
But we have some drawbacks: 1) the first time you activate the forced update on a 0.00 program, SyMenu will have to update that program because it finds nothing inside the version file. Anyway I think it's tolerable. The alerting system doesn't like me so much. It will be very difficult to explain to the users and it requires a user intervention. I don't like it; 2) probably the option (BTW I like this name: "Override the build in update") should be available for every 0.00 program and not globally. This grants a more granular control over the update process but it's very difficult to implement it because I don't have a DB for the installed applications so I don't know where to store these preferences. I fear my only choice will be to implement the global option. Well it's true that the file version could be used as a DB. Writing the version inside it, is already a sort of DB, but I'm not so happy about this approach.
Anyway this issue is real and I have to solve it in one way or another, but I have to think about the possible solution a little more because better solutions always exist. For example a different approach will be to leave all as it is today and implement a little local DB for the SPS. This will make obsolete all the file version system. This approach, that is for sure more demanding and complex, will solve a lot of other problems too so what's the best one?
Anyway this is not the priority today. If you follow this forum you already know the two things I'm working on in this period.
The first one is the complete program redraw that allows me to make it compatible with high resolution monitors.
How is this task going?
Well, very well, I've just started it and it'll be a long activity, but I've already found the right way and I can ensure that it will be available with the next version.
The second one is the automatic closing for every program opened by SyMenu when SyMenu close. Naturally it'll be an optional feature.
|
|
link
|
VVV_Easy_Symenu Posts: 159
01/08/2018
|
I understand and share your priorities. It's a very good new that you finally have found the right solution for the windows desktop zoom. Just a clarification, when I wrote "alert" I wanted to say only that it appears as "Update" (Aggiornabile) in the window of "SyMenu-Manage SPS Apps" window, not an especial user alert. Really, I'm thinking in an advanced option that disables the actual SyMenu "precaution" in the Manage SPS APPS window with the Build in update Apps (it doesn't compares the available with the installed version because the 0.00 question). Perhaps the explanation with a programming approach may have created confusion. Thank you for your attention, eager of see the new "scalable" version.
|
|
link
|