I found a bug in SetupS that I've been tracking for a long time now. Turns out if you Send your ppApps folder to SetupS, or if you perform a Regen and you have a ppApp that has no shortcuts that it will get stuck and fail to move paste the item... I'll see if I can debug it out and I'll release the first 2015 version. The funny thing is it took Windows 10's new notification center as I could see a log of what SetupS was up to and where it was getting stuck, although I had asked Freezer how to enable debug mode or how to use his method, I never found out, so I'll just use my Msgbox method through the codes functions to see which one is broken and then figure out how to fix it once I trace where it lives. Here is the bad .app, as soon as I added a fake shortcut it worked as intended. Code: [SetupS] Title=Paste As File Version=v2.1.4.0 Description=This allows you to paste your clipboard as a new file. * Note: Newer version is not free. URL=http://starpunch.blogspot.com.au/|http://cgs.vdsworld.com/click.php?id=59|http://vdsfreak.com/post/90261660490/paf Category=Office BuildType=ppApp App-File Format=v9.14.11.6.0 App-File Style=2 (INI) AppPath=%ppApps%\PasteAsFile StartMenuSourcePath=Paste As File Catalog=Office StartMenuLegacyPrimary=- Office StartMenuLegacySecondary=2 Office Flags=NotInStartmenu [Meta] Tags=File Utility|Office Publisher=Starpunch Releaser=Glenn ReleaseDate=2013 Rating=3.5 InstalledSize=2461111 LicenseType=1 (non-gratis) -EDIT- On a good note, you can now Compile SetupS (from dev kit) in Windows 10, you couldn't before -EDIT 2- hmm may actually be the registry processing section of code... Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\Background\shell\Paste As File] "Icon"="%AppPath%\\PasteAsFile.exe" "Position"="Middle" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\Background\shell\Paste As File\command] @="%AppPath%\\PasteAsFile.exe \"%V\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\Paste As File] "Icon"="%AppPath%\\PasteAsFile.exe" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\shell\Paste As File\command] @="%AppPath%\\PasteAsFile.exe \"%1\"" -EDIT- Ah - it's the RunWait86 function that is stopping it from continuing, I'll figure out why shortly. -EDIT- Here's the bug Code: Func RunWait86() If $Debug Then _ConsoleWriteDebug('@@ Debug(Trace) ' & @ScriptName & '|RunWait86(): @AutoItX64=' & @AutoItX64 & @CRLF) ;#x86_only##cs If Not FileExists($TempDir & '\RunWait86.exe') Then Local $CurrentWorkingDir = @WorkingDir FileChangeDir(@ScriptDir) FileInstall('.\bin\RunWait86.exe', $TempDir & '\RunWait86.exe', 1) Do Sleep(10) Until FileExists($TempDir & '\RunWait86.exe') FileChangeDir($CurrentWorkingDir) EndIf Return $TempDir & '\RunWait86.exe ' ;#x86_only##ce EndFunc I simply change $TempDir to @TempDir and the bug was fixed, seems $TempDir is an empty Variable if you do not provide any shortcuts... Update soon -EDIT- Also added Code: FileDelete(@TempDir & '\RunWait86.exe') to SetupS.Core in the CleanUp function (so no leftovers are leftover ) *Note this is probably not the best place for it as it will delete between item regens and have to re-install for each item that uses it... but better than that it being left behind and turning in to a zombie.
Release: Code: --------------------------------------------- v15.01.26.0 (Jan 26, 2015) --------------------------------------------- FIX: A bug where regen stops on apps with no shortcuts specified. Blank $TempDir used where @TempDir use is suffice --------------------------------------------- v14.11.6.0 (Nov 6, 2014) --------------------------------------------- FIX: A bug creating random files in C:\Windows. ADD: PC Settings to MenuDefaults.ini. http://www.lastos.org/team/1SetupS/ This was compiled in Win 10 TP, but should be fine for use by everyone.
Has Freezer given up on updating SetupS? anyway I found that another bug persisting that I have where after packaging .apz with Send To AutoBuild and it has no Flags= it will add all of them to the final .app (so you end up with them on the desktop, quick launch, root, Send To etc, instead of just defaulting to KeepAll (which doesn't interfere with anything)... So if some of the latest app updates I've done have this issue, let me know and I'll update them again (I'll look in to fixing this bug once I get my OS re-installed, my AutoIt is being weird on this install at the moment).
I don't use autobuild but as long as it doesn't create problems on regen either I (hopefully) won't be coming across that bug.
Not that I would need it, since I have no interest in using Windows 10, but have the necessary PC setting changes been made in SetupS to deal correctly with Windows 10? Just curious.
Not yet in ssControlPanel. It depends on a system macro (@OSVersion) of an older version of AutoIt -- v3.3.8.1. That version only recognizes "WIN_2008R2", "WIN_7", "WIN_8", "WIN_2008", "WIN_VISTA", "WIN_2003", "WIN_XP", "WIN_XPe", "WIN_2000". I tried updating to a more current AutoIt but that turned out to be a huge ordeal. Not only was the code trashed but had to deal with what seemed like an endless stream of bugs and crashes. And those were just the ones immediately obvious. No telling how many "hidden bugs" it was actually creating. So not trivial at all! It was a very disappointing experience for me. In the end I stayed with the devil I knew. And in fact, it'll be a trivial task to simply create a custom equivalent of that system macro using the DOS ver cmd instead -- similar to how our "_GetWINNTVersion()" function does it. For those curious, take a look at AutoIt's ChangeLog. As you can see, besides the almost 2-year gap between the releases v3.3.8.1 & v3.3.10.0 (and with no interim versions in between!), the nearly mountain of changes that were made. And this here was a huge headache for me personally & professionally: "Fixed #2576: All AutoIt EXEs and tools not working on older Athlon XP processors due to SSE compiler options.", from v3.3.10.2... Ouch.
Can you give me an apz (or pgg) where you know this is happening or occurring? As of yet, I'm unable to duplicate this problem.
Oh I wish I could, but it's when you send a single folder with a batch of apps with varying flags set, they seem to stick onto the next item (like it doesn't blank them all back to off between each .app file it loads to convert to .apz Really just extract any batch of 8 or 9 apps from the repo (with different flags set and one that has no menu items or flags set) and it will start making up it's own flags for each new .app file it generates for all the following app files it does during the automatic building of the one folder filled with extracted apz folders. -EDIT- If I can find the time to make a test case for you I will, but I tagged and compared 23000+ photos over the last week and I have just received another 20GB wortth from my other sister to sort out and add to our family collection, as well as I need to put up new curtains and shuffle some bedrooms around for the winter etc.. so if you have the time to play before I can help, let me know.
I had one tiny request. When we use %AddToHosts%, could it be made to where it creates a new (blank) line first before writing to the hosts file? I had a situation where the last line of the hosts file was something like #</yahoo-ad-sites> and so what happened was that it added the address I wanted to add right at the end of that (last) entry, rather than starting a new line. Since blank lines are no problem, I thought it would be good practice to just add a blank line first, if possible. EDIT: One thing I've been bumping up against for a long time: would it be possible to round the install-size for ppApps off to mb's? So instead of it reading 5062376, have it read 5.1 (mb). It would be better that way I think. For dual-arch apps even that is still not ideal, as it reads combined content of _x64 and _x86 folders, but that's OK.
BP brings up a good point. Probably won't know what the final default shortcuts will be for the StartMenu but I can start laying the ground-work for their release later this year. I believe there are some preview-releases (and even "leaked" copies) out in the wild.
Thanks I'll test out the multi apz fix soon, I just hope ssWPI can handle the changed bytes formatting, I'll check it out and let you know ASAIC.
Internally there's been no change to the .app/.ppg file -- it still stores the data as number of bytes. The change was just in how ssEditor displays the data or inputs it. In other words, ssWPI will not see a difference. That may not exactly be what Trouba wanted; but it won't break anything either.
question about the LastOS Tweaks files. Does the latest one always render earlier ones obsolete, or are they all meant to be kept around and applied to a new install? thanks
If you mean the ssApp(s), then yes, older ones are obsolete. At the moment, 2 people are maintaining different LastOS Tweaks ssApps with different names. Glenn maintains the "Apply.LastOS.Tweaks,.Context.Menus.&.Hosts.File_v2015.02.06_NT6_ssApp.apz" one and I the "LastOS.Tweaks_2015.04.21_NT6_ssApp.apz". The apps are pretty much the same, though lately I made some changes to mine. I also don't like the "Apply..." name because I don't naturally look for "Apply" when I think about "LastOS" Tweaks. Since I maintain it my way, if it's been a while for the other to update it, I share it the way I make it, so that's kind of the story behind the different versions. But you only have to keep the latest one, not previous versions.
Trouba doesn't mind having a HUGE list of context menu items in his menu's, but I use a lot of x768 height laptops that make his menu systems unusable - so I ditch Calculator, Notepad, Change Wallpaper and a bunch of other ones that are really not needed for most users. That is one of the few differences to our tweaks that I check, but Trouba's tweaks are preferred now days as I haven't been using my PC enough to even test tweaks, the Last time I modded anything that wasn't a photo was the done in the middle of February - so his work is much newer and better tested than my older efforts.
I'm running into a weird issue. I was working on Dreamweaver ppApp and in the ppApp.reg I have some entries where it points the program to a default preview browser (being IE). In the ppApp.reg I simply give: Code: [HKEY_CURRENT_USER\Software\Adobe\Dreamweaver CC 2015\Browser Launch Menus] "Browse Directory"="C:\\Program Files\\Internet Explorer\\" "Count"=dword:00000001 "UseTemp"=dword:00000000 "Name00"="iexplore.exe" "Path00"="C:\\Program Files\\Internet Explorer\\iexplore.exe" When I install the ppApp, without running the app at all, the reg entries above translate to "C:\ppApps\Internet Explorer\..." in the registry automatically. First I thought Dreamweaver was somehow changing this, but I tested and it occurs by SetupS itself as it also happens when Dreamweaver hasn't run yet (so, install->check registry). Since 64-bit OS has IE 32-bit as well, I tried "C:\\Program Files (x86)\\" but again it automatically converts to C:\\ppApps\\. In the very beginning I had done %ProgramFiles% but since that didn't work I thought it couldn't read the variable inside the quotation marks or something, so I gave the full path. Now I'm thinking SetupS is somehow converting Program Files paths to ppApp paths, but I see no logic in it because it also does it when not using variables.
That is the correct behavior for SetupS. Hmmm. The only work-around I can think of right now is to use script/.cmd during Post-processing to apply a separate .reg-file instead of with Registry Entries. It won't do (indirect) variable substitutions of the files listed inside scripts (or .reg-files).
Freezer, what I did also try was make a separate .reg file called from Assembly= (in the .app file), but I guess since it's called directly by SetupS it still converts the path anyway. Does that sound right? So what you're saying is I can try to call a .reg file from ppApp.cmd, or?
Yes, I believe so. Assembly (or Post-processing Registry Entries) uses the same code. The behavior you're observing was done intentionally -- mainly to facilitate converting back and forth between ssApps, ppApps, or ppGames. You might be able to "sneak" a .reg-file past using a script instead. Ditto with Assembly -- try applying the .reg-file from inside a script. You've encountered an exception, is all. Apps don't usually call on another app that may or may not exist on any given user's system. What if the user's system default browser is Firefox or Chrome instead -- either of which could also be a ppApp as well? Runtime dependencies (Java, Flash, dotNet, etc.) create similar problems. Anyway, that's probably not the solution you were hoping for. Let me know if it works or not. Maybe Glenn will have a better suggestion?
No I was of the same opinion make a cmd files and call that using MyScript.cmd: @echo off regedit /s UnParsedKeys.reg if that fails then use reg.exe /import UnParsedKeys.reg /f type method (need to google exact switches). The issue will be the x86 and x64 detection of Program Files and Program Files (x86) So you may need 2 scripts with #Is_x86# & #Is_x64# added to appropriate line (You can do it via the single .cmd as SetupS will parse the script file but not any external calls the cmd makes but I prefer to have it so you can run the .cmd to test the results without needing to use SetupS). You can call a regedit ot reg.exe from ppApp.cmd but it will not have the arch detection in place (not a problem if doesn't affect the outcome, IE you can add both Program Files and Program Files (x86) to LocalMachine's WOW6432Node sub section so the x86 version works on a x64 machine), this doesn't work for CurrentUser tho.
I had to make a separate .cmd (called from the .app file's Assembly line) which in turn calls the .reg file. That works. If I add the same line to run the .reg file to the ppApp.cmd, it won't work. The import method also didn't work from ppApp.cmd. You would be right, were it not for the fact they now make Dreamweaver in x86 and x64 versions, so that won't be necessary (unless one would for some reason want to run the x86 browser on 64-bit OS instead). In the separate .cmd: Code: @echo off regedit.exe /S "%~dp0\preview-browsers.reg" In the .reg file: Code: [HKEY_CURRENT_USER\Software\Adobe\Dreamweaver CC 2015\Browser Launch Menus] "Browse Directory"="C:\\Program Files\\Internet Explorer\\" "Count"=dword:00000001 "UseTemp"=dword:00000000 "Name00"="iexplore.exe" "Path00"="C:\\Program Files\\Internet Explorer\\iexplore.exe"
If the x86 version of the app will only run correctly on a x86 OS and not a x64 OS, then that would be the first such instance that I am aware of. Running the x64 version only on a x64 OS is standard, of course, but some folks prefer to only have one version of the app and run it on either OS they happen to have booted, especially if it is a ppApp. It's not a problem for me, but I'm just saying that for an app, that this will be unusual, though again this is standard practice for runtimes, drivers, etc. I would think that the .cmd should be able to tell whether it is running on a x86 or x64 OS and call the appropriate .reg file to allow the x86 version to operate correctly on either OS, but you are the app creator, so by all means do what you think is best. We all really appreciate that you are willing to share your work with us. All of our systems, and this web site, would be worse off without your contributions, and we all sincerely thank you for your hard work.
