I have my command line options that work for my installer, which involves the plugin NotifyIcon. Because of this plugin, I can not run my installer silently through the command line. It has one custom page MUI page over. Two questions occured to me, so if anyone can help, please do so.
I'm using MUI, so I know I have to use a separate function and then define MUI_CUSTOMFUNCTION_GUIINIT myGuiInit ! I load the code correctly and icon works for me properly.
Running the installation mínimimizado. I've dealt with "HideWindow" on . MyGuiInit OnInit and also in my own functions, and anywhere else I could think of, but that does not work very well. What I need is that the first boot installation window minimized and the icon appears on the task bar (this already works for me) and when you press the icon on the taskbar window is restored installation to continue with the installation normally.
I don't really understand your question but if you want to start the installer minimized you can do:
!define MUI_CUSTOMFUNCTION_GUIINIT myGuiInit
Function myGuiInit
System::Call 'USER32::PostMessage(i$hwndparent,i0x0112,i0xF020,i0)'
FunctionEnd
Related
Hello to you who is reading this post. About a week ago I discovered NSIS and have just about managed to finish my first installer script. I managed to find answers to pretty much all of my questions through web searches, and have managed to create a pretty elaborate installer. There is one issue I can't figure out, as everything I have tried does not work and I can't find a solution online that I understand or is specific enough to be applied to this issue.
I'm using the modern UI "MUI2". I found some code to increase the size of the rich textbox on the license page which works great, but now the text at the bottom of the window (MUI_LICENSEPAGE_TEXT_BOTTOM) overlaps it and causes some visual bugs. Setting it to an empty string does not work and setting it to a single space does not work. I managed to get it to disappear with "FindWindow" and "GetDlgItem", but I'm not exactly a programmer so I don't have the intelligence or knowledge on how to set these up correctly. What I did manage to pull off, it also removed the rich textbox, and after several hours of defeat I finally gave up and turned to the internet.
It's kind of mind blowing to me that NSIS does not provide a simple way to remove controls. I don't want the "text bottom" label there at all, I want it gone or at the very least hidden. I know the handle I'm trying to remove is "1006" because I opened up the installer in Resource Hacker and removed the label from there. What bugs the me most is that actually worked perfectly and removes the label, but it also corrupts the installer and I have to use NCRC on command line to launch it. So scratch that as a workable solution...
TL;DR my question is: how do I hide or get rid of MUI_LICENSEPAGE_TEXT_BOTTOM?
MUI2 already has a variable you can use:
!include MUI2.nsh
!define MUI_PAGE_CUSTOMFUNCTION_SHOW HideMui2Text
!insertmacro MUI_PAGE_LICENSE
!insertmacro MUI_LANGUAGE "English"
Function HideMui2Text
ShowWindow $mui.LicensePage.Text 0
FunctionEnd
If you wanted to do it manually it would be
FindWindow $0 "#32770" "" $HWNDPARENT ; Find inner page
GetDlgItem $1 $0 1006 ; Find control
ShowWindow $1 0
When using Resource Hacker you need to copy the base file from NSIS\Contrib\UIs and in your script define MUI_UI to the path of your modified UI file.
I am trying to automate an installation that starts out with an InstallShield setup.exe. That kicks off the installation of a MS Visual C++ redistributable. That leads to an error about Adobe Flash not being up to date. I have asked about how to deal with that here:
Error during automated software install using pywinauto
Once I click OK for the Adobe dialog(have to use pyautogui.click() for this for now) I see that there is an .msi being extracted. I have followed the install and it puts it into a new Temp folder under my Users\AppData directory.
How do you get pywinauto to find this new application? I have tried using
adobe = Application().connect(title_re="MyInstaller",class_name="#32770", visible_only=True)
And then try to print_control_identifiers() but get this error:
AttributeError: Neither GUI element (wrapper) nor wrapper method 'print_control_identifiers' were found (typo?)
I have checked Spy++ and Inspect and AutoIT to find the class which I can. I can't use the procid as it will always change.
Any thoughts on how to attach to the .msi process so I can then connect() to it?
Edit:
Is there a way to regex pywinauto to point to a path if I know where MyProgram.msi is? It seems to be in C:\Users\me\AppData\Local\Temp{xxx}\MyProgram.msi as I found several copies there. Thanks!
Add timeout=10 or whatever you need to connect() params. Current default timeout is zero, but it should be timings.Timings.window_find_timeout which is 5 sec by default.
Auto detection of spawned child process is planned for next major release (as well as default timeout fix).
For running an unpacked .msi file you need msiexec standard Windows command in method .start(). Play with it in cmd.exe manually first starting from msiexec /?.
Here is how I deal with the fact that InstallShield exe extracts to an .msi in (into my DownloadedInstallations folder). Yes, timeout is important, but also identifying the new msi window that opens is too. (Also, I found that wait_for_idle had to be FALSE but don't remember why. YMMV :) ).
exe = pywinauto.Application(backend="uia").start(exepath, wait_for_idle=False)
Now it's going to unzip the .exe into .msi installer and that could take a while, and since the .exe window might be named the same as the .msi window must be careful not to attach to the exe window too early and must wait for the .msi window to open!! So, add an appropriate timeout in seconds. The dialog window may not exist yet here, so it's CRITICAL to use class_name of MsiDialogCloseClass especially if the title of the exe and msi are the same. This will identify the .msi window specifically, whenever it arrives.
title = "Enter Title of your App - InstallShield Wizard"
msi = pywinauto.Application(backend="uia").connect(title=title,
class_name="MsiDialogCloseClass",timeout=120)
And for the final touch, in a line I always forget, must use the title again to get the dialog window (for reasons I don't yet understand)
dlg = msi[title]
EXTREMELY HELPFUL way to view all control identifiers at this point is:
print(dlg.print_control_identifiers())
This is what hours of trial and error yielded. To continue on, now you can click buttons, like this:
dlg.Next.wait("ready",timeout=2)
dlg.Next.click()
And to click on radio buttons, this works (there may be other ways that do, but I could never find how to get a handle on the buttons by name)
dlg['I &accept the terms in the License Agreement'].wait('enabled').click()
Then moving on
dlg.Next.click()
dlg.Install.wait("enabled",timeout=5)
dlg.Install.click()
We have a Basic MSI installer project. On a certain dialog, we do validations of data provided by user and then throw appropriate message using the MessageBox().
Now when the MessageBox comes up, it comes up with the message we want and an OK button.
We have an issue w.r.t the locale of this OK button. When tested on English, French windows 2008 machine we can get the OK button, where OK is in English. When we use the same installer on a Spanish windows machine then the same OK button comes up with OK in Spanish.
I'm not able to figure out what's the cause of this behaviour. Any hint/help would be of great help.
/Avadhut.
It's unclear from your question exactly what API you call, and in exactly what scenario. Note that for almost everyone, displaying the OK button in the "native" language of the machine will not be confusing, so only causes problems during the QA process.
The MessageBox API of Windows is localized to the same locale as Windows itself. By contrast, MessageBoxEx is documented to take a language parameter, although when I looked, a commenter said it doesn't always change the default localization. (My guess would be that the requested language was not available on the commenter's machine.)
If you're showing a message from within a MSI DLL custom action, it's better to use MsiProcessMessage than MessageBox as MsiProcessMessage will parent its window correctly. I suspect you're using a ControlEvent, which is implicitly avoided in a silent installation, but MsiProcessMessage will also not show its message during silent installations without requiring any extra work; if using MessageBox in an execute sequence action, you would have to check UILevel manually. However it's unclear from the documentation whether the buttons on an MsiProcessMessage message box will be localized.
When I try to give custom icon while creating InternetShortcut that particulat icon is not there in created InternetShortcut. Default icon is comming.
Here is code:
WriteINIStr "$SMPROGRAMS\Launch_APP.url" "InternetShortcut" "URL" "http://localhost:9080/myapp/index.php"
WriteINIStr "$SMPROGRAMS\Launch_APP.url" "InternetShortcut" "IconFile" "$ReadmePath\A.ico"
CreateShortcut uses IShellLink to create shortcuts and is not supposed to be used to create internet shortcuts. The documented interface you are supposed to use to create internet shortcuts is IUniformResourceLocator. NSIS does not have a native instruction for this but it can be called by the system plugin using its COM syntax. To set the icon you would have to QueryInterface for IPropertySetStorage and set PID_IS_ICONFILE. In the end you are just going to end up with the same .ini file which is why a lot of examples (NSIS and other stuff) just write using the .ini API.
You could try adding IconIndex=0 to the .ini but my guess is that the icon path is wrong or icon caching is getting in the way.
Have you tried clearing the icon cache or testing on a different machine?
Thanks for using NSIS.
So - There is function CreateShortCut (nsis.sourceforge.net/Docs/Chapter4.html#4.9.3.4). it is intended to create any shortcut Windows supports. You should use it. If you find some specific case where it does not work, feel free to mail to Devs in NSIS contact list or create ticket in their bug-tracker.
I am using NSIS to create an installer for my application. NSIS Mondern UI, to be specific.
This installer is multi-lingual and I am using
!insertmacro MUI_LANGDLL_DISPLAY
!insertmacro MUI_LANGUAGE
etc to ask the language input to the user. On one of the machines, I am not getting the "Select Language" popup. But if I use the normal NSIS commands (not MUI) like LoadLanguageFile, LicenseLangString etc., it works perfectly fine.
What could be the reason for this behavior? Is it related to any other system/Windows level setting??
Other MUI commands/instructions work perfectly on this machine. Any help greatly appreciated.
There are a couple of things that could be going on here:
If you use the MUI_LANGDLL_REGISTRY_* defines, NSIS will try to remember the language and not ask again (MUI_LANGDLL_ALWAYSSHOW turns this off)
If NSIS decides that this machine is only able to display one language (code page issues etc) it will not show the dialog, you can override this with MUI_LANGDLL_ALLLANGUAGES