- NSIS Discussion
- disclaimer, processing page of checkboxes
Archive: disclaimer, processing page of checkboxes
jmichae3
23rd October 2007 10:08 UTC
disclaimer, processing page of checkboxes
I am trying to have a disclaimer page, and then a page of checkboxes.
I get the disclaimer page, but I get no page of checkboxes (there is a setup.ini file that contains all the control's attributes). when it finally gets to the page that displays the settings, it installs. then you are forced to click install where it installs yet again. and I don't even know why. :-(
I don't see enough documentation on File and ReadIniStr to exactly understand how to use this, because every example uses the $PLUGINDIR\test.ini and I can't find such a file.
None of the examples come with any documentation explaining how they work. they use a lot of undocumented magic numbers.
I can't seem to get anywhere.
can I get someone to fix this (help me out)? I'm a newbie.
flizebogen
23rd October 2007 18:47 UTC
First Add
SetOutPath "$PLUGINSDIR"
after InitPluginsDIR. This determines the Target Directory.
Use File "setup.ini". No need for the Parameter "/oname".
Then edit setup.ini and replace all section headers with [Field n] n = Field Number
[Field ooextras] is not valid. Maybe you need to set the NumFields value according. I don't know exactly if this is required. In InstallOptionsEx it's not.
Regards,
Sebastian
jmichae3
24th October 2007 07:29 UTC
That got the checkbox page to appear.
it still attempts to install everything regardless of my settings. twice. I think NSIS has a few bugs.
ReadINIStr ${TEMP1} "setup.ini" "Field 2" "State"
DetailPrint "Install 2:ooextras=${TEMP1}"
ReadINIStr ${TEMP1} "setup.ini" "Field 3" "State"
DetailPrint "Install 3:openclipart=${TEMP1}"
ReadINIStr ${TEMP1} "setup.ini" "Field 4" "State"
DetailPrint "Install 4:ure=${TEMP1}"
ReadINIStr ${TEMP1} "setup.ini" "Field 5" "State"
DetailPrint "Install 5:sdk=${TEMP1}"
ReadINIStr ${TEMP1} "setup.ini" "Field 6" "State"
DetailPrint "Install 6:jre=${TEMP1}"
This showed empty strings after the =.
later on I try to do this:
ReadINIStr ${TEMP1} "setup.ini" "Field 4" "State"
StrCmp ${TEMP1} 0 skipure
ExecWait 'OOo-URE_1.3_Win32_install_en-US.exe'
skipure:
but the string compare is not working apparently. the checkboxes are returning empty strings every time.
and wouldn't you know it, ReadIniStr is poorly documented too. it reads in whole parameters for controls, but there is no documentation on that.
I am trying this using ${If} ${TEMP1} == 1
and it seems to work much better.
I definitely think StrCmp is the wrong thing to use with checkboxes, because what I am getting back from a checkbox is a number, not a string.
in the setup.ini, if I change the state from 0 to 1, the value passed through NSIS is 0 no matter what value I choose.
how do I detect the state of a checkbox and have it work? NSIS seems to be broken. I am using 2.3
jmichae3
24th October 2007 07:37 UTC
correction, ${If} works just as badly as StrCmp.
checkboxes are completely broken. nothing I do seems to compare the value.
here's the new code.
jmichae3
24th October 2007 07:55 UTC
I noticed all the examples with checkboxes are broken. no matter what state the checkbox is in, they all return the same value. NSIS is broke.
kichik
24th October 2007 21:07 UTC
- Why use nsDialogs' welcome.nsi when you have MUI_PAGE_WELCOME?
- Why use both nsDialogs and InstallOptions?
- You have both Page instfiles and MUI_PAGE_INSTFILES. Use only one. If you're using the MUI, use the page macros.
- Warnings should not be ignored. They'll usually point you to a bigger problem.
- You are reading from setup.ini located in the installer's working directory. Use a full path to setup.ini or InstallOptions.nsh's macros.
- Do not use "C:\Program Files". Use $PROGRAMFILES.
- Do not use relative paths with ExecWait. Use absolute paths or you'll get the same problem as with the INI files.
- No need for XPStyle when using the MUI.
- /ENABLECANCEL is only useful for the last page. For any other page, it's implicit.
- Isn't there a NSIS installer for OOo already? Why not base your code on it?
jmichae3
25th October 2007 06:36 UTC
- what's a page macro?
- what's MUI_PAGE_WELCOME? (there are no examples, so show me instead of telling me what's wrong)
- the only warning I got was about BUTTON var not being used and that it was wasting memory.
- I can't use a full path while I am testing and developing. and I don't think that's what's really messing things up is it? Please stick to the problem at hand.
- thanks for the tip on program files.
- relative paths with execwait - what problem is that? the problem I am having is that lately for some reason I see them shell out and then immediately exit. another bug in NSIS I assume. someone please fix it. Is that the problem? This used to work fine until I changed my code to work with checkboxes instead of buttons.
- what do I use instead of XPStyle for MUI?
- I was unaware of any NSIS installer for OOo or I would be using it now. It's not posted on the OOo site in any place I can find. Do you know how I can find it?
jmichae3
25th October 2007 06:38 UTC
MUI_PAGE_WELCOME is not in the documentation either.
pospec
25th October 2007 06:54 UTC
so show me instead of telling me what's wrong
This isn't smart way to ask questions. RTFM please, there is ${NSISDIR}\Docs\Modern UI folder.
another bug in NSIS I assume. someone please fix it.
You don't use a help, do you?
jmichae3
25th October 2007 07:36 UTC
You don't need to curse at me.
I did a find-in-folders for the word MUI_PAGE_WELCOME in all the docs and in all the source code. and I finally found an obscure HTML readme.html that briefly mentions
!insertmacro MUI_PAGE_WELCOME
but nothing is said about this command. this is the only documentation there is.
so how do I get the disclaimer in the MUI_PAGE_WELCOME? I don't see how this is going to solve my problem. All I basically need is checkboxes that work and a disclaimer. if I can't have checkboxes that work, I am doing back to the old buttons that do work, but it's a messy ugly installation procedure you have to run through twice.
win32 system calls don't have a problem with relative paths. only NSIS does for some reason.
Afrow UK
25th October 2007 13:11 UTC
Basically you shouldn't mix Page <whatever> with MUI_PAGE_<whatever> when using Modern UI, except for using Page Custom.
The reason it installs twice, as already mentioned, is because you have a Page InstFiles and an !insertmacro MUI_PAGE_INSTFILES. They are both the same except the MUI_PAGE_INSTFILES version is for Modern UI (hence the MUI).
As for there only being one documentation for MUI_PAGE_WELCOME, why would there be more than one? Either way there are hundreds of examples on this forum and many on the Wiki. Take a look in your Examples\Modern UI folder.
Stu
kichik
25th October 2007 19:20 UTC
jmichae3, you're a funny man. Not using full paths causes the "problem at hand". I gave you all the answers for all of your "bugs". Use them or ignore them - it's up to you.
Afrow UK
25th October 2007 20:29 UTC
Yes not using full paths will mean any operations will be performed not relative to where the installer is located, but relative to $OUTDIR (SetOutPath).
Stu
jmichae3
25th October 2007 20:57 UTC
I'll take note of that in my program, since I am not using copyfiles or anything liek that, only execwait.
I am trying instead examples\mui\welcomefinal.nsi for a base on which to build, since I can't seem to get enough information to get the old one going.
1. how do I include a section for the main installer itself (all MUI examples has this missing)? and will the main installer execute last or first?
2. how do I assign a number to a variable? I'm pulling my hair out trying to find anything in the documentation that lets me do this. no assignment operator, can't push/pop, strcpy won't work, IntOp won't work, nothing.
Afrow UK
25th October 2007 21:10 UTC
$OUTDIR (set with SetOutPath) sets the working directory and any applications launched from NSIS (using ExecWait for example) will inherit the same working directory.
1. I'm not sure quite what you mean, but anything in between Section and SectionEnd is code that will be executed on the INSTFILES page. What do you mean by 'main installer'? There's only one unless you are launching another installer executable with Exec or something?
2. StrCpy $R0 0
NSIS treats strings as integers and vise versa depending on the instruction you are using.
Stu
jmichae3
26th October 2007 01:53 UTC
If you look at the example, you will notice that the section they produce code for is only for the checkbox item/option. there is no section that handles the equivelant of 'main' (I am not sure how else to put it - the section that gets called regardless of the options, and hopefully first).
I don't know how I would ensure the order of section execution (options after main).
I tried StrCpy with an integer. I get an compile error. it wants a string.
[just discovered it only works with variables, not registers]
think I am close to a workable solution!
pospec
26th October 2007 05:39 UTC
think I am close to a workable solution!
Can you show it to us?
jmichae3
26th October 2007 06:30 UTC
this one seems to work, but there is no concept of 'main' section. silly this MUI - options only? ridiculous.
unless someone can tell me how to make an option grayed-out and checked (they are all checked by default).
I would also like to have some items unchecked by default if that is possible, like the developer packages, because most users aren't going to want or need that. but I don't know how to do that.
the examples only show 1 option in the whole thing, and it's checked.
I've been looking through System.nsh under !macro MUI_PAGE_INSTFILES and I can't quite understand it. I don't know how to tie some code into that page. it's hidden from view I guess (anyone have any better success interpreting it?). it takes no parameters.
pospec
26th October 2007 07:20 UTC
I think that words silly and ridiculous are far from what NSIS is.
Q: I don't know how to tie some code into that page.
A: ...anything in between Section and SectionEnd is code that will be executed on the INSTFILES page.
Truly now - do you REALLY use NSIS help? If you do then you should check the "section" reference, there's something about /o switch. It may be useful for you.
Afrow UK
26th October 2007 11:02 UTC
See Section and SectionIn in the documentation to check and disable a section.
To make a 'main' section as you call it which cannot be unchecked, simply do not give it a name or prefix its name with a -. This is all covered in the documentation if you spent a little bit longer reading.
Blaming NSIS because you are impatient does not give you credit for us to help out. I am assuming you are no computer programmer so perhaps it would be better if you asked/payed somebody here to do your work.
Stu
jmichae3
27th October 2007 02:16 UTC
I think I got spoiled by MSDN. I write programs in several languages now, though I don't claim to be anything close to an expert. I used to be a language junkie. I dabble in multithreading and other disciplines. I am not a UNIX programmer, though I've forked once or twice. 'nuff about me.
I don't know how I passed over the docs directory. I assumed the help file was all there was. who wouldn't? I simply wasn't expecting 2 sets of docs.
Well, after trying the MUI codebase, I discovered that the options are executed *in series-parallel*. in other words, they are executed in order, but ExecWait doesn't get finished on one section while another section/option starts executing at the same time. I was hoping for something simply sequential. Is it supposed to do that? [rhetorical]
I set the output dir to "." to solve the problem of relative paths. [I wonder if ExecWait ".\extras.exe" would work without having to do that.]
as a result, I am back to the original nsDialogs codebase. it immediately installs without showing the checkboxes.
Yeah it would be great if someone wrote this for me, then I could study it and see where I went wrong, because there are many quirks of this language I just don't understand, like why I can't seem to mix MUI and nsDialogs and get working results (maybe they are not meant to?), why pages won't display. If I bang at this long enough I am sure I'll figure something out on my own.
jmichae3
27th October 2007 06:30 UTC
I also discovered that executing ExecWait is like executing an Abort, much to my dismay. this is nothing like the standard win32 calls. I sure wish they would rewrite this part of NSIS so it passes through to the next statement when it's done.
Afrow UK
27th October 2007 11:41 UTC
I have no idea what gave you that idea but ExecWait much like Exec and ExecShell will move onto the next instruction when it is finished. You must have something else stopping the install. Perhaps it's because it is ExecWait that you are assuming it is stopping the install, but it is just waiting for your executable to finish. Use Exec if this is the case.
Any relative paths used will be relative to $OUTDIR. Why can't you just use full paths? You have all the constants available such as $EXEDIR and $INSTDIR.
There is nothing wrong with mixing nsDialogs with MUI.
If you want to do some virtual asynchronous sections then you want to replace your ExecWait with Exec.
Are you missing a Page Custom? You cannot show a custom page anywhere else.
Stu
jmichae3
27th October 2007 22:31 UTC
because during testing setup.nsi is in F:\cd\openoffice.org\2.30\win\
and during execution I won't know what drive letter (cd-rom) the user will run setup.exe from: could be e:\, could be d:\, could be something else. so I can't set an exact drive letter and path. I need to use the current directory.
no, I *don't* want asynchronous sections. ...as I was complaining about MUI options. I am getting that with ExecWait for some reason. (?) I am beginning to wonder if NSIS spawns each option as a separate thread.
page custom? what about it?
demiller9
28th October 2007 06:54 UTC
I need to use the current directory
That is exactly what $EXEDIR will do.
Sections run sequentially from a single thread. ExecWait will wait for the process that it starts, but not for processes that
that process starts. You might be running into a common problem that a package you are trying to install has not waited for its children. Try searching for options that will make it wait.
Don
pospec
28th October 2007 09:44 UTC
...it really whips the llamas ass
jmichae3
31st October 2007 07:05 UTC
apparently this is exactly what OpenOffice is doing - spawning children - "unzip into this directory and then execute". and this is exactly the source of the problem. with all the OpenOffice installers. thanks for helping me to nail it down. fortunately, extracting the clipart takes long enough that by the time it's done extracting in parallel with the openoffice install, openoffice is finished (if the user notices the dialog box).
Thanks everyone for your help - I think this is as far as I can go - MUI-only and it's as good as it's going to get. I've gotten nothing else to work.
Afrow UK
31st October 2007 11:22 UTC
If you know what the child processes are called you can put in a loop until they are finished using FindProcDll.
Stu
jmichae3
2nd November 2007 00:14 UTC
do you have a reference/docs for that? I can't find FindProcDll in the docs, nor on MSDN. I checked kernel32.dll and user32.dll using dumpbin /exports it's not in there.
is this some sort of plug-in DLL?
[never mind - found it via google here on winamp forum - written by IceMan]
jmichae3
2nd November 2007 01:56 UTC
it works great now, except that one of the installers gave an abort retry ignore on instmsi.exe and instmsiw.exe, which has seemingly nothing to do with my program. other than that, the installer is perfect now (if not close to it), and all appropriate sections wait for "setup.exe" to appear and disappear.
thanks for the tip!