I'm using AppleScript to open files in Ableton Live, which is not officially scriptable. But I have at least managed to open files with it.
What I'm wondering is if it's possible in some generic way to check if the currently opened file within the application (it can only be one project open at a time in Ableton Live) has been modified, i. e. is unsaved? Or does it require the application in question to be officially scriptable?
Or is there otherwise any way of checking if a top menu item is disabled or not? I'm thinking that checking if the "Save project" menu item is clickable or not could work as a boolean for if the project has been saved or not.
Related
I have renamed the binary and used rcedit to set both ProductName and InternalName but the "Opens with" context menu has remained as Electron.
Is it possible to rename this reference without building Electron?
After forgetting about this question and after a bit of research I found that upon launching any program for the first time Windows will set a registry property "FriendlyAppName" and never update it again.
Manually modifying this on my system resolved these context menu names, however I'm unsure if the modified binary will retain the desired FriendlyAppName on systems that have never run the application before.
I don't see an option to tell VC++ what the current project is, so that I can search within a specific project within my solution, rather than the whole solution.
Is it something that happens as a side-effect of some other operation or can I somehow explicitly select which project is the current one?
currently opened file on which you opened the Find/Replace dialog belongs to a certain project. So that project is basically the "Current Project"
Right click on a project in the Solution Explorer and select 'Set as Startup Project.' The 'Startup' project is the "current" project.
This question has a longer answer that it would seem. To make the Current Project selection, go to Solution Explorer and click on the desired project so that it is highlighted. It is not necessary to make the project your StartUp Project, but doing so will highlight the project as required to make it the Current Project for the search. You can make the project selection before or after opening the find/replace dialog. If you do not have a project selected (by selecting the solution), there is no current project and nothing gets searched.
However, there is at least one alternative. If the Property Manager is opened, a selection there will also set the current project. If both are opened, it appears that the last selection becomes the current project. This information is for VS2017, but probably it has been that way for many older versions since the Current Project search option has been around for a long time.
I'm working on making slight changes to a legacy VS 2008 & MFC project, including changes to the WinAPI/MFC *.rc resource file. I have made those changes, e.g., changing a menu string (for IDR_MAINFRAME, if it matters) from "New Scan" to "New Organism" on one computer, commited to VCS, and tried rebuilding the project on another, practically identical configuration (not sure if relevant), which is when I ran into problems.
Currently, I have
changes to the menu from within the VS resource editor that do not propagate into the application (old values remain)
changes to the about dialog that do propagate into the application
an RC file that contains no mention of "New Scan"
no file, including binaries, containing "New Scan" (though, as mentioned, this might be due to encoding)
I have
cleaned and rebuilt
manually cleaned and rebuilt
deleted the *.res file and compiled just the *.rc file into a *.res just to make sure the paths there are alright
modified the configuration so that (Project -> Properties -> Resources -> Command Line) has an absolute path to the *.res file.
verified that the current module is indeed the exe being executed via GetModuleHandle
verified that all calls to FindResource and LoadResource pass NULL as the current module, meaning the resource should be loaded from the exe
verified using ResEdit that the resource within the exe contains "New Organism", even though it shows "New Scan" when run. I verified the #define for the resource is the same number as the number reported by ResEdit. Verified there's no other similar resources in the exe.
verified that I'm running the same exe I'm inspecting and tried running it from both the IDE and from Windows Explorer.
inspected all (two) non-system DLLs that get loaded (as reported by the output window and dependency walker) using ResEdit and both of them belong to a 3rd paty library and none of them contain any menu resources (they only contain manifests).
tried changing/removing the command that loads the menu (CFrameWndEx::LoadFrame) and verified it forces the application to fail.
verified that having an IDR_AppnameTYPE MENU with a second copy of the menu doesn't help (see thomiel's answer below)
Using google
To no avail. I am especially unsure where the original string, "New Scan", is coming from and how come changes to my about dialog propagate and changes to the menu don't. How do I make the changes to the menu propagate to the *.exe itself?
In case of a SDI or MDI: Not only change IDR_MAINFRAME but also IDR_??????TYPE, which is the menu displayed when you have an open document.
I have had the exact same problem. This is going to sound crazy, but if you create a SUB menu in the menu item, and then delete the APS AND RES files, and then SAVE ALL and to a REBUILD of the ENTIRE SOLUTION, you should be OK. Please contact me if you have any other questions. I'm happy to help.
It seems that MFC will cache the menu items in registry when you quit your application. To prove it you can copy your program to a new machine and runs it. If it displays the modified menu items normally, it means MFC uses cached menu items on your own machine.
You can clean the registry key to make your modifications take effects. The registry entry may locate at
HKEY_CURRENT_USER\Software\Local AppWizard-GeneratedApplications\MyMFCApplication1
-or-
HKEY_CURRENT_USER\Software\{your company}\{your project name}\Workspace
based on the MFC version.
I am building a VS 2010 installer, and I want to copy files to app folder depending on what options I select in UI (UI is not simple, so the only option is to show custom dialogs in Install custom action).
The problem is that custom action is actually executed after files are copied already.
One possible solution I can think of is to install all these files into the app dir, and then delete some unnesessary files in custom action. But these files are "secure" in some way, so I don't want to copy them to filesystem, even for a short period of time.
Any thoughts?
If your files shouldn't ever be on the filesystem, you have a problem in the requirements. The .msi storage itself is an open format and can be read by many tools, so if someone knows the file it's possible for them to find and extract it manually.
I agree that it's better to avoid deleting the files after they've been installed for two reasons. One: it avoids wasted work, and two: it won't cause repair scenarios due to missing files that Windows Installer thinks should be present. You should probably figure out how to determine whether these files should be present at an earlier stage of the installation, and set properties that cause this to happen (disable components by condition, or change feature states).
Most controls in MSI dialogs use installer properties. For example, a checkbox may use a property named MY_CHECKBOX which is set to a value or it's empty, based on whether the checkbox is checked or not.
These properties can be used to condition files:
select your setup project in Solution Explorer
click File System Editor button from Solution Explorer top pane
select the file you want to condition
in its Properties pane set Condition field to the condition you want, for example
MY_CHECKBOX = "value"
I have a VB6 project in Visual Source Safe 6.0. When I open the project I want to Check Out (Get) all the files in the project so that I can edit them.
I have the VSS Options (within VB6) set to act on the Project recursively, but when I check out the project.vbp it only checks out the project file, not all the modules, etc. Those files all remain write protected until I individually check out each one.
SOLUTION: Select the Project.vbp and, from the Tool>SourceSafe menu choose Check Out, you get a dialog which lets you choose ALL files (you get a checkbox for each and a button for Select All).
Why I had problems
For some reason, if you right-click on the Project in the Project tree and choose Check Out it doesn't give you that dialog. It just checks out the Project file. (However, if you do the same thing and Check In, it gives you the dialog with the checkboxes for each file. I guess that that point it knows that you have more than one file to check in.
FWIW generally speaking you get more options when choosing 'Check out...' via the Tools menu as compared with choosing 'Check out' from the right click context menu. One of the more useful 'Advanced' options is to check out with out 'getting' (i.e. replacing) your local file.