Archive: Features request :)
Features request :)
Heh, I think it would be great to add a Subsection Rename hint to the documentation (SectionSetText Name "-Caption" :), 'cause it's not very amazing to search for this thru source code :)
Now, the feauture request :) Is it posible for InstType to became Multi-lingual?
And at last: can you help me to find sources for MagicLime? I would like to add some features (for the first make it a Plugin :) to it and I'm too lazy (now) to write such a cool fading by myself :)
Heh
In addition to my poor English your cool board system ate all my closing brackets :)
Hope you'll understand me...
Russian.NLF
In addittion: russian text for the button "Show Details" is too long (modern2.exe). So, you could either change it to "Äåòàëè" or enlarge the button...
Uninstaller :)
Huh, I'm having a great pleasure spaming at your forum! :)
What about the uninstaller translation? There are options (/LANG=) at uninstaller commands and there are translated uninstaller strings at MultiLinguage.nsi. But neither your example uninstaller translation or my own uninstaller trans. works...
It's 3:23 a.m. at my country and really hard for me to think and scan your sources already... :) May be you have a $(LANG) variable and I must save it during install process and restore at uninstaller start? Who knows... :)
I hope I'll get tomorrow (today) at the morning and find answers to all my questions... Good luck to me... :)
Now, the feauture request Is it posible for InstType to became Multi-lingual?Already in the todo list.
And at last: can you help me to find sources for MagicLime? I would like to add some features (for the first make it a Plugin to it and I'm too lazy (now) to write such a cool fading by myselfIt is now called UberSplash and its sources are avaiable in the contrib dir.
In addittion: russian text for the button "Show Details" is too long (modern2.exe). So, you could either change it to "Äåòàëè" or enlarge the button...Talk to the translator and have hime send me a new translation.
What about the uninstaller translation?It won't remember the language you have used in the installer. The first option is the system language, then what you choose in .onInit. You can, as you said, save it somewhere from the registry.
Bugs and features...
I'm spotted bug (or feature :)) at InstallOptions: if the user closed the window with the X icon (heh, close mark at the top-right of the window), WM_CLOSE message sent directly to parent, so dialog finishes with "success" result. Hm... Strange behavior, I think :)
I've patched ParentWndProc for my needs by inserting that before the last return:
if (message == WM_CLOSE)
{
PostMessage(hConfigWindow,WM_USER+666,0,IDCANCEL);
return 0;
}
Tested and works fine...
The second "feature" was found at ModernUI.nsh: by removing the "goto done" line at MUI_HEADER_TEXT macro (and decreasing StrCmp jump value) we'll receive some additional functionality (for the CPU consumption cost to follow all other branches of course): for example it will be easier to create InstallOptions pages at uninstaller:
!insertmacro MUI_HEADER_START 2
!insertmacro MUI_HEADER_TEXT 1033 "Options" "Select options."
; Uninstall options dialog
Push $7
CallInstDLL $8 dialog
Pop $0
StrCmp $0 "success" "" hdrend
!insertmacro MUI_HEADER_TEXT 1033 "Uninstalling" "Wait."
!insertmacro MUI_HEADER_STOP 2
hdrend:
One more question: is there any way to tell uninstaller we want to cancel uninstallation process from "un." functions (can be very useful if we are using InstallerOptions for example)?
By the way: I was very suprised to found uninstaller using the same engine as installer, so we could pack and use anything during uninstallation process... Great thing!
Re: Bugs and features...
Originally posted by brainsuckerYou can add your own function to .onNextPage and .onPrevpage, but this is a little bit easier. I'll change this stuff a bit.
The second "feature" was found at ModernUI.nsh: by removing the "goto done" line at MUI_HEADER_TEXT ...
One more question: is there any way to tell uninstaller we want to cancel uninstallation process from "un." functions (can be very useful if we are using InstallerOptions for example)?Have you tried Abort or Quit?
I've tried Abort - it succesfully returns to previous page, even if page is first (May be this behaviour should be patched?). Quit... hm... Telling the truth I'm lost that command in tons of printed NSIS documentation :)... Beside this, isn't it a emergency quit command? No callabacks and so on...
Have you tried Abort or Quit?
Abort returns to the previous page only in un.onNextPage.
I can make the plugin command auto insert pop commands, but the question is, what would be a good syntax. Both of your suggestions are not good INMHO. The first one, as you said, forces one to use $0. The second can conflict with plugins that might want /RET as a paremeter. How would NSIS know if it's a parameter or a return statement?
I made some changes to the Modern UI macro system. You can now add a new page to the SetPage function for InstallOptions. Make sure that you change the ${CURRENTPAGE} variable and call SetPage again depending on what the user does on the IO dialog.
Originally posted by kichikThat's right! I'm at general a newbie to NSIS, and don't know other places where I can place my InstallOptions dialog (during uninstall!) :). Any ideas? Of course, I can wait for example 'till un.onInitDialog receives control and handle Cancel (i.e. call Abort) here, but this way is smelting bad... The other way (huh, worse than previous i think) is to wait for uninstall to begin and call Abort as the first command... May be I'm broken my logic somewhere at university today, but I don't see any other ways to do that damn Cancel :)
Abort returns to the previous page only in un.onNextPage.
Both of your suggestions are not good INMHO.Ok, ok... Any other ideas?
Originally posted by Joost VerburgOk, I have to wait for nightly CVS snapshot :(, and than I'll try it...
I made some changes to the Modern UI macro system.
Use Quit in un.onNextPage.
We have thought of some ideas for that plugin stuff but couldn't find any good ideas. Users can not put /RET= too, so it doesn't really help.
int values
Integer values at NSIS are int 32 or int 64? int or uint? thanx :)
They are strings :)
You can compare as unsigned or signed using IntCmpU or IntCmp, calculate as signed using IntOp, and print as whatever you want with IntFmt. All ints, when converted, are held in a 32 bit int.
There was a while back a lengthy discussion between myself, KiCHiK and a few others about the return value of plugin calls. It is far from a simple problem.
Due to the way NSIS works internally it doesn't make sense to try and define target variables for each return value (as one of your ideas suggested) and the other idea of using $0 assumes that there is only a single returned value.
How about if there were a second stack, cleared on every plugin call and then plugins stack their return values onto this second stack. There'd be no problems with stack corruption because it wouldn't be altering the main stack, it could cope with many return values, and we could add a PopRet op ala normal Pop but for the return value stack. I don't think script code should be allowed to Push to this special stack, only the plugin.
Re: Bugs and features...
Originally posted by brainsuckerHm... Time passed... Heh... Just expecting comments, cause I don't like the idea of shipping my patched InstallOptions with my software for the rest of my life... :)
I'm spotted bug (or feature :)) at InstallOptions: if the user closed the window with the X icon (heh, close mark at the top-right of the window), WM_CLOSE message sent directly to parent, so dialog finishes with "success" result. Hm... Strange behavior, I think :)
eccles will be working on this among some other stuff for IO.
dll::proc
Just noticed dll::proc plugin call passes parameters to stack at left-to-right order, so the first argument pops out as last... Strange behavior, I think... For example it make functions with variable arguments count much more complicated! And what about other languages examples? For example all C/++ calling conventions pass arguments at right-to-left order...
Have I any powers to affect the NSIS developers? :((
No, because that's the way the old CallInstDLL way worked. You push push push, and get it from bottom to top, same as right to left. Maybe I will add a compiler flag that will make it push from right to left. C++ calling convention has nothing to do with it, the parameters are pushed to the NSIS stack.
the same
in the assembler you push 3 push 2 push 1, but when C compiler compiles it actually reverses the order, so proc(1,2,3) looks like the same push 3 push 2 push 1! That's not the matter of stack we use, but the matter of usability,:) That is not a lecture, just a note...
Ok.. I understand you position, but d::p is actually a new feature to nsis 2, so it's the best time to apply changes! Latter it will much more complicated... In fact all plugins will be updated and NSIS scripts too! Please....!!! You know not worse than me, that such "features" could grow like a snow ball....
By the way: adding a compiler flag -> incompatible plugins (anyway, for some order of passing)...
mydll::myfunc arga argb argc
Translates to (pseudo code)
push arga
push argb
push argc
So the top of the stack (i.e. the first item to be popped) is argc.
Hence in the plugin c/c++ code when it does popstring it gets arguments in reverse order. This has NOTHING to do with the compiler
and EVERYTHING to do with the NSIS stack and original CallInstDLL behaviour.
I don't see a problem with this, so the c/c++ code has to popstring args in reverse order, your problem is what exactly? This never affects a user of NSIS scripts or plugins, just plugin developers.
dll::proc
Huh, I've mentioned C compiler and Asm, just like examples of REAL LANGUAGES args passing conventions. :)
Ok, I understand the thing: when plugin system developed it looked easyer for users to push parameters at right order (first...last).
But now, when dll::proc macro incorporated, it is very unlikely somebody will use the old CallInstDll method, and such proffesionals, which will do, the are able to revert the order (last..first). And for macro (that's wrong name for it, I know, just short :) it's nothing to do... That will require small recoding of present plugins, but these small spendings will make life easyer for plugin developers a lot!
Now, WHY we should do that? Ok, there are several reasons:
1) If users passes the arg at first place, the plugin may want to take that arg in hands at the very beginning.
2) The main reason: formal arguments lists, as they named in C. The plugin function may expect the variable number of args (for example, let this function to be the printf (wsprintf) clone). The function starts poping out args, but it don't know where to stop to read the real output format specification (something like "hello, %s=%d"), and it don't know the count of args. (Yes, we could invert the args order and user will call [dll::printf 1982 "a+b" "hello, %s=%d"], but...)
Okay in the situation where the first parameter popped tells the plugin code how many more parameters it should grab I see your point.
As for the stacking thing it turns out the code has been changed since then. The way it worked before was that there was a custom opcode for plugin commands and that opcode stored string ids so it was limited by opcode storage space, that is no longer true.
Re: dll::proc
I agree, pushing the first parameter last makes sense :) Yes, just like real languages like C (worth noting that pascal at least used to do it the other way, which sucked).
The version in CVS is updated to do reverse-order.
-Justin
Originally posted by brainsucker
Huh, I've mentioned C compiler and Asm, just like examples of REAL LANGUAGES args passing conventions. :)
Ok, I understand the thing: when plugin system developed it looked easyer for users to push parameters at right order (first...last).
But now, when dll::proc macro incorporated, it is very unlikely somebody will use the old CallInstDll method, and such proffesionals, which will do, the are able to revert the order (last..first). And for macro (that's wrong name for it, I know, just short :) it's nothing to do... That will require small recoding of present plugins, but these small spendings will make life easyer for plugin developers a lot!
Now, WHY we should do that? Ok, there are several reasons:
1) If users passes the arg at first place, the plugin may want to take that arg in hands at the very beginning.
2) The main reason: formal arguments lists, as they named in C. The plugin function may expect the variable number of args (for example, let this function to be the printf (wsprintf) clone). The function starts poping out args, but it don't know where to stop to read the real output format specification (something like "hello, %s=%d"), and it don't know the count of args. (Yes, we could invert the args order and user will call [dll::printf 1982 "a+b" "hello, %s=%d"], but...)
coooollll :)
I have to wait for the evening to download the latest CVS snapshot, so I couldn't check now, but you haven't updated the plugins for sure...
So, there is a bit of work for somebody...
But justin did update most of the plugins :D
Re: Bugs and features...
Originally posted by brainsuckerI've now added your fix, thanks. :) Available from the usual place.
I'm spotted bug (or feature :)) at InstallOptions: if the user closed the window with the X icon (heh, close mark at the top-right of the window), WM_CLOSE message sent directly to parent, so dialog finishes with "success" result. Hm... Strange behavior, I think :)
/NOUNLOAD
thanx eccles.
I've got another 'feature request' (to the whole nsis developers team): couldn't you add something like permanent subj (/NOUNLOAD) option? In some cases there will be many calls to plugin (for example System plugin :), and using /NOUNLOAD every time... hm :(
Allow NSIS to unload plugin everytime? A resource consuming solution,
futhermore plugin may want to save something in it's own static vars... (bad habbit, I know :)
P.S. Something like 'SetDllUnload on|off' will do the thing, I think... ;)
Done. Added SetPluginUnload manual|alwaysoff.