kichik
30th June 2007 17:18 UTC

nsDialogs
  It's time for something really new. I wrote a plug-in that should replace InstallOptions in the near future. It should be faster, more capable, far more customizable and easier to use. Currently it can create any type of control, call callback functions directory from the script and create dialogs without all the INI files overhead.

It supports specifying units in pixels, dialog units and percentage - both positive and negative. It has a callback for TEXT field changes and for the back button. It's way faster. It has complete control over the style of the generated controls, including extended styles.

When it's done, it'll be even possible to create a real-time InstallOptions to nsDialogs converter that'd simply read the INI file and create the dialog according to it.

At the moment, creating a control requires quite a lot of parameters, but in the future it'll have a library of macros or functions that'd allow easier creation that requires nothing more than a type and location - just like with InstallOptions.

Play with it and let me know if you have any suggestions or issues in mind. Attach cool examples here or useful macros you write and I'll probably include them when nsDialogs goes into CVS.

Afrow UK
30th June 2007 17:28 UTC

That's very nice. Can ExecuteCodeSegment be used in any NSIS plugin?

Stu

kichik
30th June 2007 17:30 UTC

Yes, any plug-in. It has been added in NSIS 2.03 and as far as I know, this is the first plug-in to use it.

edit: actually, there's already my incomplete nsXML.
edit2: the UAC plug-in too...

Afrow UK
30th June 2007 18:23 UTC

I cannot believe that went unnoticed lol
I can use that in my ButtonEvent plugin :D

Edit: Done.

Stu

Backland
30th June 2007 22:41 UTC

Excellent work, sounds like a major improvement in terms of custom installer dialogs.

Comm@nder21
1st July 2007 17:57 UTC

looks nice :)

kichik
1st July 2007 18:22 UTC

And here's the first version of the script that converts existing INI files to a new dialog. Shouldn't be too hard to have it generate the script itself as well.

The plug-in itself has changed a bit and now takes the text parameter as the last parameter to nsDialogs::CreateItem.

kichik
6th July 2007 12:46 UTC

And with browse buttons too.

Backland
10th July 2007 19:55 UTC

This is really great for for creating on the fly interfaces, but will it be able to setup event handlers for controls defined in the INI?

kichik
10th July 2007 21:16 UTC

The NOTIFY flag will eventually be supported by the IO2nsDialogs function. But you can already do the same when using nsDialogs directly with nsDialogs::OnClick and nsDialogs::OnChange which is not even supported by InstallOptions.

Backland
12th July 2007 08:22 UTC

Is it possible to set nsDialogs::OnClick for controls created from an IO script? that would be the ultimate solution for getting the best of both formats.

kichik
12th July 2007 17:21 UTC

Yes. All the conversion does is read the INI file and use nsDialogs according to it. You can read the HWND from the INI and use nsDialogs::OnClick with it.

Animaether
14th July 2007 22:25 UTC

just wanted to say: very cool. I'll be awaiting the usual first few days of "zomg - it just imploded!" before tinkering with it myself, after which our highly customized installer will probably be moving to nsDialogs from InstallOptions. Should save a bunch of code and - more importantly - run faster (takes a second on some of the heavier dialogs on my P1.6M). Might keep the INIs, as currently there's no GUI interface designer for nsDialogs, is there? :)

Afrow UK
14th July 2007 22:27 UTC

That would be handy :D

Stu

Red Wine
15th July 2007 21:55 UTC

I want to transfer some scripts where in custom page leave function there are several ReadINIStr conditions and actions' dependency.

How should I do that?
Are there any suggestions and/or tips?

Red Wine
16th July 2007 13:30 UTC

Well... I guess I should start from scratch, thanks :)

Animaether
16th July 2007 13:53 UTC

your question is a bit vague, so I'm not sure what the answer would be. The way I'm reading it right now is that you're using the INI file as a form of variable storage - and depending on the multiple values in the INI file (in the variables), you take a particular action.

Sounds to me like you could...
A. Stick to using an INI file - except that for each control's callback you'll need to write out the value manually.
B. For each control's callback, write to a different text file. (Essentially the same as the ini - but more work)
C. For each control's callback, assign the value to a runtime variable - and instead of reading from an ini / text file, read the runtime variable.

In essence, nsDialogs makes creating the dialogs more flexible, faster (code execution-wise) and independent of ini file storage. Those are the immediate Pros. The immediate cons are that a lot of the automation is gone. I.e. changing a text box's text doesn't automatically store this - you'll have to store this yourself (in a variable of file), through a function that you have to write out, and then associate with the text box's change handler. So on the face of it - it's certainly a good bit more work. I suspect that as you get used to it, though, it'll prove to be a great enhancement.

Eventually some GUI editor for use with nsDialogs will come up and in each control's property sheet there'll just be a "code block to execute when changed" sort of text box, along with a small "code block name", which together simply set up all the Function handling and such for you.

Of course, if it remains something where you think "InstallOptions did just fine for me, and I'm more comfortable with it" - well, InstallOptions doesn't appear to be going away, and the InstallOptionsEx author(s) might have a thing or two to say about the Pros/Cons and decide to continue development there as well :)

Afrow UK
17th July 2007 22:54 UTC

Just a suggestion, would be nice to have NSD_ macros for OnClick etc, and have GetFunctionAddress in them.

Stu

Brummelchen
18th July 2007 03:30 UTC

/ot: would be nice to handle pluginsdir in memory - not on disk :p

still working on a "installer script language"? :D

kichik
18th July 2007 06:04 UTC

Brummelchen, you can't load DLL files from memory. How is this related to a new scripting language?

Afrow UK
18th July 2007 15:59 UTC

If you don't want to use $PLUGINSDIR, extract the DLL yourself and use CallInstDLL instead. For example, the NSISArray plugin has built in support for this while still using the macros.

Stu

Brummelchen
18th July 2007 17:37 UTC

as long i write installers i dont care on pluginsdir.
as i started with portables like portableapps.com i wish
to have that in memory - but ok, this is really /ot now.

i appreciate a newer gui with modern commands - but i dont
really get the point on mouse-effects or similar jokes
on an "installer script"

but - if nsis goes away from a simple installer script -
and it does - why not to ask for that option above!? ;)

kichik
18th July 2007 17:41 UTC

Brummelchen, implement a memory-DLL loader and I'll include it.

Brummelchen
18th July 2007 17:48 UTC

"i'm afraid dave - i cant do this" :D
i am no programmer - i can do only scripts :(
but if that would be possible - much appreciated :)

kichik
18th July 2007 17:50 UTC

Brummelchen, you can't load DLL files from memory.

tdue
19th July 2007 08:32 UTC

Hello,

Is there an automated method of converting a IO ini file to a nsDialogs script? I THOUGHT the io.nsi file in the zip file posted earlier would do it, but that does not seem to be the case.

In any event I have been playing around with NSIS (and HM NIS Edit) for the last couple of days. My installer experience is limited to InstallShield 10.5 and the build-in MSI installer in Visual Studio. I must say I am vastly impressed with NSIS.

I am seriously lacking integration with Source Safe and Visual Studio though, but I guess I can manage without... for now ;)

kichik
20th July 2007 16:55 UTC

io.nsi only displays INI files using nsDialogs. In the future, it should also be able to create a script.

bnicer
20th July 2007 16:59 UTC

Well done!

I'd give my left toe in exchange for something that's better. Manually converting the controls seems to be the first step along the way. I've encountered a problem:

SetCtlColors $TEXT 0x000000 transparent

The nsDialogs Welcome.nsi example uses:

"" 0xffffff

Is "transparent" not supported?

kichik
20th July 2007 17:09 UTC

"transparent" is a feature of NSIS and not nsDialogs, so it's supported just like in InstallOptions. nsDialogs simply forwards relevant messages to NSIS for handling the colors.

bnicer
20th July 2007 17:21 UTC

Oddly enough,

SetCtlColors $TEXT 0x000000 transparent

does not make the background transparent.

SetCtlColors $TEXT 0x000000 0x0000ff

changes the background to blue. ???

vbguy
20th July 2007 17:47 UTC

Originally posted by bnicer
Oddly enough,

SetCtlColors $TEXT 0x000000 transparent

does not make the background transparent.

SetCtlColors $TEXT 0x000000 0x0000ff

changes the background to blue. ???

kichik
20th July 2007 17:51 UTC

Add the WS_EX_TRANSPARENT extended style to the CreateItem call and it should work.

bnicer
20th July 2007 18:04 UTC

I always get white.

Compile Welcome.nsi with a transparent text background.

Function nsDialogsWelcome


    nsDialogs::Create /NOUNLOAD 1044

    Pop $DIALOG


    nsDialogs::CreateItem /NOUNLOAD STATIC 


${WS_VISIBLE}|${WS_CHILD}|${WS_CLIPSIBLINGS} 0 120u 10u -130u 20u "Welcome to nsDialogs!"

    Pop $HEADLINE


    SendMessage $HEADLINE${WM_SETFONT} $HEADLINE_FONT 0


    nsDialogs::CreateItem /NOUNLOAD STATIC 


${WS_VISIBLE}|${WS_CHILD}|${WS_CLIPSIBLINGS} 0 120u 32u -130u -32u "nsDialogs is the next generation..."

    Pop $TEXT


    SetCtlColors $DIALOG"" 0xffffff

    SetCtlColors $HEADLINE"" 0xffffff

    SetCtlColors $TEXT 0xffffff "transparent"


   nsDialogs::CreateItem /NOUNLOAD STATIC 


${WS_VISIBLE}|${WS_CHILD}|${WS_CLIPSIBLINGS}|${SS_BITMAP} 0 0 0 109u 193u ""

    Pop $IMAGECTL


    StrCpy$0 $PLUGINSDIRwelcome.bmp

    System::Call 'user32::LoadImage(i 0, t r0, i ${IMAGE_BITMAP}, i 497, i 0, i ${LR_LOADFROMFILE}) i.s'

    Pop $IMAGE

    

    SendMessage $IMAGECTL${STM_SETIMAGE} ${IMAGE_BITMAP} $IMAGE


    Call HideControls


    nsDialogs::Show


    Call ShowControls


    System::Call gdi32::DeleteObject(i$IMAGE)


>FunctionEnd 

>

kichik
20th July 2007 18:13 UTC

That example doesn't use WS_EX_TRANSPARENT, you need to add it. Replace the 0 that comes after the styles with ${WS_EX_TRANSPARENT}. Don't forget to copy its definition from nsDialogs.nsh.

bnicer
20th July 2007 18:18 UTC

WS_EX_TRANSPARENT extended style; how do I define it?

I have, so far...

nsDialogs::CreateItem /NOUNLOAD STATIC ${WS_VISIBLE}|${WS_CHILD}|${WS_CLIPSIBLINGS}|$(WS_EX_TRANSPARENT) 0 120u 32u -130u -32u "nsDialogs is the next generation..." 

kichik
20th July 2007 18:19 UTC

Take the definition from nsDialogs.nsh and replce the zero before 120u with it.

bnicer
20th July 2007 18:21 UTC

Thanks. Our replies keep on crossing. I'll try that.

FoBoT
21st July 2007 21:29 UTC

does the BrandingImage stuff work with this yet?
I copy/pasted the commands below into InstallOptions.nsi pointing to my .ini file

ChangeUI all "${NSISDIR}\Contrib\UIs\modern.exe"
AddBrandingImage top 20
SetBrandingImage "$PLUGINSDIR\logo.bmp"

from a working InstallOptions version and it displays correctly except the logo is missing from the top of the page

FoBoT
21st July 2007 22:13 UTC

also, is the functionality in place yet to change the cancel/next button labels? for example my old .ini files has:

[Settings]
NumFields=2
Title=Control Panel
CancelEnabled=1
CancelShow=1
BackEnabled=1
CancelButtonText=Exit
NextButtonText=Enter

so that the cancel/next buttons display custom text

thank you

Animaether
22nd July 2007 01:17 UTC

You can always do that manually, FoBoT. In fact, it's more flexible with nsDialogs as you can enable/disable / change texts on those buttons dynamically based on what the user is doing - with any dialog item rather than only those that would cause an InstallOptions exit.

GetDlgItem $0 $HWNDPARENT 1 ; Next button
SendMessage $0 ${WM_SETTEXT} 0 "STR:Custom Next"
GetDlgItem $0 $HWNDPARENT 3 ; Next button
SendMessage $0 ${WM_SETTEXT} 0 "STR:Custom Back"