[How To Copy Crack File Into Installation Directory
Lorean Hoefert
After having spoken with Qt support and got the answer that it's actually not possible ("It is possible only after extracting. After extraction, you can use copy or move operation, unfortunately there is currently no other way.") I decided to use the AdminTargetDir as the second target directory. This because there's no other way to pass dynamic variables to the IFW. So after installation I call a "finalizeInstall_patch.bat" file passing the TargetDir and AdminTargetDir and this will move the libraries directory from TargetDir to AdminTargetDir. Why a .bat patch file ? because it's actually not possible to move a directory using the methods provided by the IFW. Qt support just opened a suggestion-ticket for our problem: -project.org/browse/QTIFW-595
Trying to install scale list cleanup utility. I have downloaded it, but it says to copy it into the "installation directory." Where do I find this installation directory? I have AutoCADlt 2008 running on a Windows 7-64bit operating system. Can't find anything in the Program file that says installtion directory.
When I go into Programs-autodesk-autocad lt 2008, the only things available in that folder are a folder names "migrate custom settings" and two shortcuts "attach Digital Signatures" and "autocad lt 2008". When I try to copy and paste the cleanupscales files to this location and open it, it gives me this error message:
Is there a way to tell the pack installer to install to a different directory? I would think that I would like to install to a more "global" directory so that the entire software tree is visible to multiple users on my team - and not have each person install fundamental files to a unique location on each of their machines. The situation is made worse in that the vendor has placed the RTE_Device.h (and other files) in this location and has instructed me to edit them for certain configurations. I feel like I am missing something fundamental about the pack as I can't see User\Appdata\Local\.... as a useful place to store code that will be edited as part of a development/production process.
When you create a new project, files that you need to modify for you project will likely be copied to the project directory. Best not to modify items in the PACK directory. IF you need to modify something, you should copy it to your project and edit it from there.
However, when I run the Pack Installer, it comes up at the top with: Pack Installer - C:\Users\username\AppData\Local\Arm\Packs - and then, as far as I can find, no option to change this. It does appear that I can "Manage Local Repositories" and set up a development repo to sort of do what I want ... but again, I am mostly surprised that Keil picking my directory is the standard operation.
I expect that it should be easy to have my project software all installed to a standard network location that makes it easy for me to share it with team members and include it in multiple different projects.
And I agree that I shouldn't have to edit anything in there - but that is where my vendor put files (like RTE_Device.h). Is it standard procedure to just copy files you want to edit into the project? And then the compile knows to take them from the local project before the pack? I am guessing that must be in the include directory order specified somewhere?
If it was a fresh install, it asked on the 1st screen where you wanted the tools and where you wanted the packs. This is stored in the TOOLS.INI file. You can always change the path and then copy the packs to where you changed this too.
You are going to want to actually create a new project using your processor of interest (if you have more than 1, just pick one) before you to go far. This will clear some things up for you. Where the PACKS are stored is not an issue.
As to editing RTE_Device.h - could you please expand on why I don't need to edit it? And by edit - I mean use the configuration wizard - because it has to be writable for me to use the configuration wizard - and as far as I can tell, that is certainly required - at least on a board by board basis.
What you should not do is edit the RTE_Device.h file in the PACK directory. Create a new project and place it where you want to (not in the PACK directory). Feel free to run the configuration wizard and change the RTE_Device.h for your project. The reason they install these are read-only is so that people don't accidentally change the files in the PACK directory.
If you are using an example project from the PACK, don't try and edit it in the PACK area. You can copy a whole set of examples to some place that is yours and you can feel free to edit them there. If they are still read-only after copying them you can modify them so they are read-write.. You may use the configuration wizard on these files.
Thanks again - to be clear, I have made new projects as well as copied example projects. I agree that one shouldn't edit the files in the pack. I guess that is why I am so confused about how the pack is distributed and how the pack install directory isn't easily changeable. If I want to have my entire team to share the same codebase - then this pack needs to be placed in an area that isn't isolated on a single machine (neither the Appdata/Local nor the tool install directory C:\Keil_v5). I guess I will change the directory using the TOOLS.INI and have everyone on the team do the same.
I am curious how others are handling this is they want to have production code where they can revision control and archive the entire build. Again - I figured this would be such a standard thing to do - and I was looking for the "proper" way to do it. Somehow, editing TOOLS.INI seems like a bit of a hack.
The idea was all DLL files should be copied from the THIRDPARTY_BIN_DIR to the binary directory. In my case the THIRDPARTY_BIN_DIR is a variable found during configuration and looks something like this: c:\thirdparty\bin
However, when I run my script the third party DLL files do NOT end up in the bin folder. Instead a new folder bin is created inside the install bin folder and the files are added there. Like:
bin\bin\mylib.dll
However, I still think that this behavior is non-intuitive. The most common case is probably that you want to copy files from the source folder to the destination folder, especially when you specify a file matching pattern. But this is only my personal opinion and I can certainly imagine other use-cases where the current behavior can be useful.
I've just installed V2. The installation did not give me the option for a desktop shortcut (I've tried reinstalling to check this). While I can find the app in the apps list and pin to the taskbar I like to keep shortcuts to all my photo applications in a folder. The requires that I know the .exe file location. I was expecting to find the V2 .exe file in C:\Program Files\Affinity\Photo which is where V1 is located. After a lot of searching and (maybe just my system) fiddling about with permissions on the folder I found the V2 .exe file in C:\Program Files\WindowsApps\SerifEuropeLtd.AffinityPhoto2_2.0.0.1640_x64__3cqzy0nppv2rt\App. Given the effort to find the file I'm wondering why the V2 .exe file was put in this location.
If you're talking about plugins you've added to Photo, you'll see that Photo 2 uses a different plugins folder in the Preferences. You could copy the plugins to that folder, or change where it points. (But I would not recommend simply pointing to the folder that Photo defaulted to, as it might disappear if you remove Photo).
They've switched to using Windows MSIX technology to install/update the applications. I'm not sure of all their reasons for doing that, but it's largely the same way that applications from the Microsoft Store are handled in Windows 10/11. And Windows chooses where to put the application.
There really should be specific instructions available for these shortcuts. I don't regularly use the windows start menu for much of anything, and this has been an hour-long hassle for me to get my shortcuts back (including breaching the recommended security on the WindowsApps folder looking for the Affinity installs (which did not result in acquiring working shortcuts)). I am very disappointed by this oversight. Hopefully the new features will be worth all this stress.
Same problem. I have spent the past several hours attempting to get my command lines that worked fine with Affinity Photo V1 to work with V2. I have several programs that allow me to launch an external editor and none of them like the new alias system. Specifying %LocalAppData%\Microsoft\WindowsApps\AffinityPhoto2.exe or C:\Users\Dan\AppData\Local\Microsoft\WindowsApps\AffinityPhoto2.exe ends with an error message that says "AffinityPhoto2.exe the file can not be accessed by the system". I can launch V2 at the command line with C:\Users\Dan\AppData\Local\Microsoft\WindowsApps\AffinityPhoto2.exe or just AffinityPhoto2.exe so I am not sure what to think.
So, now for a bit of follow up. And apologies but the precise order of what I've done is lost in the mist of exploration and button presses. I started this morning by starting from the desktop shortcut I'd created yesterday.
I then moved on ...... When I came to explore V2 this morning I tried to invoke V2 from DXO but got a message along the lines of (sorry - I've been fiddling for a couple of hours so can't remember exactly) "can't access". Or something like that - the upshot is I couldn't invoke V2 from DXO. Since I now know where the V2 app is I went to the folder to find I didn't have permissions that I had set up yesterday - so I think I couldn't start V2 by double clicking the .exe in that folder - even though the desktop shortcut I'd created yesterday worked fine. I've now regiven myself permissions and am getting V2 to invoke via DXO and ACDsee but - I have now had a couple of requests to re-enter my licence/account details. I have no idea why my permissions changed overnight. anyway, I've done a couple of restarts and things seem to be working OK at the moment.
795a8134c1