Oh, sorry for not answering that before. I plan to add it to the next version, but I'm unsure of the quality of the implementation. The next version will be launched within this month (that's what I say instead of saying next 2 weeks). The new features are costing some annoying bugs in the code, which need to be fixed before release. The readme was not even touched, with the exception of the change log. So you see how I'm going...
Do you have any time limits for this? I could make sure that I do things as fast as I can if you want me to.
InstallOptionsEx
368 posts
Originally posted by deguixthanks, but that's not necessary. just had to decide if i should release another beta or the final version (which would require that feature). knowing that i got some more time, i will just release another beta of my software.
Do you have any time limits for this? I could make sure that I do things as fast as I can if you want me to.
I found another bug:
In InstallOptionsEx 2.4.2.b4, if you use an IPAddress control with Flags=DISABLED, the control is not editable, ok, but it doesn't appear grayed out.
Thanks, regards
In InstallOptionsEx 2.4.2.b4, if you use an IPAddress control with Flags=DISABLED, the control is not editable, ok, but it doesn't appear grayed out.
Thanks, regards
I don't know why the OS doesn't gray it out, but I can't do this right now. If there was an example on the web that shows how to implement this, then I would probably find a way to include it in the plug-in. I probably don't have enough knowledge to judge how to implement that.
The "\|" (and "\{", "\}") feature was added. Any more small features/bug fixes/patches to include into the next version?
I'm already thinking: "What am I going to do for 2.4.2 beta 6 right now?". Plenty of code revamp I would say. The code is getting messier and messier, and so huge... I need to split everything up for clarity. Maybe using a .cpp file for every control? This would make implementations for new controls easier.
I'm already thinking: "What am I going to do for 2.4.2 beta 6 right now?". Plenty of code revamp I would say. The code is getting messier and messier, and so huge... I need to split everything up for clarity. Maybe using a .cpp file for every control? This would make implementations for new controls easier.
Maybe this time the release will be even slower than what I expected. I simply hated my previous implementation, but now it's a lot easier to split items of arrays.
Yathosho, don't worry about IOEx due dates for releases. I always miscalculate due dates and this is how I'm. It's never ready in time... 🙁 but always has something of better quality than expected in it... 🙂
Yathosho, don't worry about IOEx due dates for releases. I always miscalculate due dates and this is how I'm. It's never ready in time... 🙁 but always has something of better quality than expected in it... 🙂
I think my last post was swallowed. If not, I apologize for the duplicate.
There was a bug in this function, where in the case of ListItems with variables after ConvertVariables() was called, the old string length nSize was returned. This lead to crashes and string truncation.
DWORD WINAPI myGetProfileString(LPCTSTR lpKeyName)
{
*szResult = '\0';
int nSize = GetPrivateProfileString(pszAppName, lpKeyName, "", szResult, BUFFER_SIZE, pszFilename);
if (nSize > 0)
{
ConvertVariables(szResult);
nSize = lstrlen(szResult);
}
return nSize;
}
Also, closing a DIRREQUEST dialog in any way - 'x', 'cancel or 'ok' - seems to send a State=0 and Notify=ONNEXT to the main validation function, but not all the time - only if it's one of the first things you do on the page.
Lastly, the default MUI/NSIS directory page shows disk usage requirements and free space. Is there access to those variables from inside IOex or NSIS?
There was a bug in this function, where in the case of ListItems with variables after ConvertVariables() was called, the old string length nSize was returned. This lead to crashes and string truncation.
DWORD WINAPI myGetProfileString(LPCTSTR lpKeyName)
{
*szResult = '\0';
int nSize = GetPrivateProfileString(pszAppName, lpKeyName, "", szResult, BUFFER_SIZE, pszFilename);
if (nSize > 0)
{
ConvertVariables(szResult);
nSize = lstrlen(szResult);
}
return nSize;
}
Also, closing a DIRREQUEST dialog in any way - 'x', 'cancel or 'ok' - seems to send a State=0 and Notify=ONNEXT to the main validation function, but not all the time - only if it's one of the first things you do on the page.
Lastly, the default MUI/NSIS directory page shows disk usage requirements and free space. Is there access to those variables from inside IOex or NSIS?
I made several changes now to ListItems, the buffer allocation... I need to review my changes, but from what I did up to now, all those bugs you said are fixed for the next version.
Now, about the question, there are no NSIS variables for retrieving that information. You have to get them on your on using NSIS. Now NSIS questions shouldn't be in this thread.
Now, about the question, there are no NSIS variables for retrieving that information. You have to get them on your on using NSIS. Now NSIS questions shouldn't be in this thread.
I hate to ask you for a release when you're not ready, I hate when people ask me for that too.
So, can you give me a hint on the DIRREQUEST closing bug? I'm trying to push out a new installer on Friday and it's the only piece looming over my head.
So, can you give me a hint on the DIRREQUEST closing bug? I'm trying to push out a new installer on Friday and it's the only piece looming over my head.
Ok, I'll release it tomorrow morning with untested parts of the plug-in.
InstallOptionsEx 2.4.2 beta 5 - DLL + Source
Hmmm... this was not completed in today morning, but I wasn't satisfied to release it with annoying bugs, so I spend the time fixing some more bugs...
Also, as you may have noticed, the files for all versions for IOEx are hosted in the NSIS Wiki now. After the first stable build is released, all of them will be deleted (or at least I think so).
This version brings a lot of big changes. In this version, RichText and Image controls were implemented, along with the BufferSize key name for "Settings" section, the new notification queuing and escape characters for "|", "{" and "}", and more types of images. Other changes include:
I didn't have much time to test everything, but now you have a chance to test what's new. Also, I still need to implement flags for the Image control and some more code for transparency.
One more thing, I couldn't put support for "\\" characters for most of the controls that support the use of a list of items for input and/or output. I might be able to add that to the next version later.
To download IOEx, go to InstallOptionsEx wiki page
Hmmm... this was not completed in today morning, but I wasn't satisfied to release it with annoying bugs, so I spend the time fixing some more bugs...
Also, as you may have noticed, the files for all versions for IOEx are hosted in the NSIS Wiki now. After the first stable build is released, all of them will be deleted (or at least I think so).
This version brings a lot of big changes. In this version, RichText and Image controls were implemented, along with the BufferSize key name for "Settings" section, the new notification queuing and escape characters for "|", "{" and "}", and more types of images. Other changes include:
- Added RichText control.
- Added BufferSize value name for Settings section. A note though, everything, including Type value for all fields are affected.
- Added ReadOnlyTxtColor and ReadOnlyBgColor value names for Text and RichText controls.
- Added ONTEXTSELCHANGE notification flag for RichText controls.
- Bitmap, Icon and Animation controls have now fused together into a control called Image. The old control names are still supported for compatibility.
- Image controls now use GDI+ or OLE when needed. So there are new file types supported: .jpg, .jpeg, .gif (GDI+ or OLE), .png, .tiff, .wmf, .emf (GDI+ only).
- Older INI files braking notice: Renamed icon names for ToolTipIcon value name to INFORMATION,EXCLAMATION and STOP, as defined under the icon resources for the State value name for Image controls.
- Added "\|" escape characters for ListBox, DropList, ComboBox controls.This applies to list based value names only.
- Added "\|", "\{" and "\}" escape characters for ListView and TreeView controls. This applies to list based value names that do not use just numbers only.
- Fixed internal memory leaks and bugs.
- For Link and Button controls using DIRREQUEST flag:
- Fixed the non-disabling "OK" button when a non-folder item was selected (like My Computer).
- Added ability for the State INI value name to specify the initial folder shown in the DIRREQUEST dialog.
- Now FONTREQUEST and COLORREQUEST flags for Button and Link controls output the control state even if a value is specified for the RefFields value name.
- Fixed string not being truncated at the maximum buffer size allowed when Text and Password controls returned (IO bug).
- Fixed Link and Button controls with DIRREQUEST flag: "|" character was appended everytime to the end of ListItems value name.
- Corrected the formula to convert pixels into points for Link and Button controls with FONTREQUEST flag.
- Fixed Link and Button controls State value name return value when used with FILE_OPENREQUEST and MULTISELECT flags: String was truncated to the first 1023 characters (1024 w/ the terminator character).
- State INI value name for ComboBox controls now uses the text specified for the state if it is not one of the items specified in ListItems.
- HSCROLL and VSCROLL flags won't work anymore if specified for controls that do not support this flag. The effect is simply useless.
- Re-added EXTENDEDSELCT and REQ_SAVE flags for compatibility purposes with IO.
- Fixed bugs #1287731 and #1283528.
I didn't have much time to test everything, but now you have a chance to test what's new. Also, I still need to implement flags for the Image control and some more code for transparency.
One more thing, I couldn't put support for "\\" characters for most of the controls that support the use of a list of items for input and/or output. I might be able to add that to the next version later.
To download IOEx, go to InstallOptionsEx wiki page
Background of Welcome/Finish
NSIS\Examples\Modern UI\WelcomeFinish.nsi
Picture 1: With standard InstallOptions.
Picture 2: With InstallOptionsEX
I know it has already been stated that ModernUI may not work with InstallOptionsEX for various things, but I hope this particular problem may be fixed in the future? InstallOptionsEX has many features I like to use 🙂 Thanks very much for writing it, by the way.
(PS: I tried to manually set the background color with
SetCtlColors $MUI_HWND "" "${MUI_BGCOLOR}"
GetDlgItem $MUI_TEMP1 $MUI_HWND 1203
SetCtlColors $MUI_TEMP1 "" "${MUI_BGCOLOR}"
[...]
But it does not seem to fix the issue.
Posted by Deliverator on 08-22-2004 11:52 PM:It seems this problem is back again? When replacing InstallOptions.dll with InstallOptionsEx.dll, the background of the page is not rendered correctly. I have attached a screenshot of:
When using this with the Modern UI my Welcome and Finish pages are not displayed correctly.
The background of the window is gray, and the background of the text is white.
What am I doing wrong?
NSIS\Examples\Modern UI\WelcomeFinish.nsi
Picture 1: With standard InstallOptions.
Picture 2: With InstallOptionsEX
I know it has already been stated that ModernUI may not work with InstallOptionsEX for various things, but I hope this particular problem may be fixed in the future? InstallOptionsEX has many features I like to use 🙂 Thanks very much for writing it, by the way.
(PS: I tried to manually set the background color with
SetCtlColors $MUI_HWND "" "${MUI_BGCOLOR}"
GetDlgItem $MUI_TEMP1 $MUI_HWND 1203
SetCtlColors $MUI_TEMP1 "" "${MUI_BGCOLOR}"
[...]
But it does not seem to fix the issue.
I still didn't update the file. I have to upload every single file from this thread to wiki yet. You were downloading an older version of IOEx. I didn't think it would take that long to upload all those files, but now I know. Sorry if I didn't tell you that before...
Now it's ok to download, but I didn't upload older versions to wiki. This is still not a big issue. If you want older versions, just search the thread.
The new version works great, thanks. A few notes:
I thought the ComboBox (DropList) control had a broken pulldown menu on Windows 98. But it's a common problem, and here's the scoop:
"The reason is that when you specify the height of the control, you are specifying it's height when OPEN not when closed. ... you can use SetWindowPos() to increase the height, or specify a greater height when creating it in the first place."
Specifying a greater height in the .ini works as expected.
msvs 7.1 users will need this:
#ifndef USER_TIMER_MAXIMUM
#define USER_TIMER_MAXIMUM 0x7FFFFFFF
#endif
#ifndef USER_TIMER_MINIMUM
#define USER_TIMER_MINIMUM 0x0000000A
#endif
There's an alternative, which is to set the winver I think, but the above works just fine.
I thought the ComboBox (DropList) control had a broken pulldown menu on Windows 98. But it's a common problem, and here's the scoop:
"The reason is that when you specify the height of the control, you are specifying it's height when OPEN not when closed. ... you can use SetWindowPos() to increase the height, or specify a greater height when creating it in the first place."
Specifying a greater height in the .ini works as expected.
msvs 7.1 users will need this:
#ifndef USER_TIMER_MAXIMUM
#define USER_TIMER_MAXIMUM 0x7FFFFFFF
#endif
#ifndef USER_TIMER_MINIMUM
#define USER_TIMER_MINIMUM 0x0000000A
#endif
There's an alternative, which is to set the winver I think, but the above works just fine.
i don't quite understand how to use the "\|" escape characters. i also think the more feature are getting implemented, the more the overview of the documentation suffers.
Hehe. Don't blame me. Maintaining both plug-in and documentation is quite difficult.
This escape character only works for any value name which supports to input or output a list of items. A list of items is a list containing items that has the "|" character basically separating them (there are also some which use "{" and "}").
One exception for this is when a value name supports to input or output a list of items with only numbers, because there are only numbers + the "|" character allowed in there. "\|" is not a number.
When you use it in those conditions stated above, it results into a "|" character.
Common example: "ListItems" value name.
The use for "\{" and "\}" is even more complicated. They only work for those values that actually use "{" and "}". Example: "State" value name for ListView and TreeView controls.
Also, don't forget that "\\", "\n" and "\r" are not supported on most of the value names supporting list of items as input or output, except for "ListItems" and "State" value names for ComboBox and DropList controls. The "\\" -> "\" effect is applied before the "\|" -> "|" effect is applied. This is the thing that I should fix in the next version.
One "simple" code example of the usage:
Just a note: you always should use the flag CHECKBOXES w/ the StateImageList value name, or the flag won't work. Also the file has to exist, so you should change the path first.
BUG: When StateImageList points to an invalid file, it still applies the CHECKBOXES flag normally. This flag uses the default checkboxes when this happens. Those checkboxes don't have the features this TreeView control has.
This escape character only works for any value name which supports to input or output a list of items. A list of items is a list containing items that has the "|" character basically separating them (there are also some which use "{" and "}").
One exception for this is when a value name supports to input or output a list of items with only numbers, because there are only numbers + the "|" character allowed in there. "\|" is not a number.
When you use it in those conditions stated above, it results into a "|" character.
Common example: "ListItems" value name.
The use for "\{" and "\}" is even more complicated. They only work for those values that actually use "{" and "}". Example: "State" value name for ListView and TreeView controls.
Also, don't forget that "\\", "\n" and "\r" are not supported on most of the value names supporting list of items as input or output, except for "ListItems" and "State" value names for ComboBox and DropList controls. The "\\" -> "\" effect is applied before the "\|" -> "|" effect is applied. This is the thing that I should fix in the next version.
One "simple" code example of the usage:
You can't apply this to the "State" value name in this case because the CHECKBOXES flag turns it into a "number-only" list of items. Also, see that the "\\" -> "\" transformation doesn't happen in there.[Field 1]
Type=TreeView
Left=0
Right=-1
Top=0
Bottom=-1
ListItems=\{\\\|A\|\\\}{\{\\\|A1\|\\\}|\{\\\|A2\|\\\}}\{\\\|B\|\\\}
State=0{1|2}3
Flags=CHECKBOXES
StateImageList=C:\Dev\NSIS Source\Contrib\Graphics\Checks\modern.bmp
Just a note: you always should use the flag CHECKBOXES w/ the StateImageList value name, or the flag won't work. Also the file has to exist, so you should change the path first.
BUG: When StateImageList points to an invalid file, it still applies the CHECKBOXES flag normally. This flag uses the default checkboxes when this happens. Those checkboxes don't have the features this TreeView control has.
a feature request
would it be possible to add a feature, which allows me to specify a default directory for contols (i.e. filerequest).
let's say the user has to specify a file in on of my ioex pages and that it's most likely that this file is stored in a specific directory (i.e. my documents). i would love to have the option to specify this directory, when the installer initialises. when clicking on browse (filerequest dialog), it would start browsing in that specified directory.
would it be possible to add a feature, which allows me to specify a default directory for contols (i.e. filerequest).
let's say the user has to specify a file in on of my ioex pages and that it's most likely that this file is stored in a specific directory (i.e. my documents). i would love to have the option to specify this directory, when the installer initialises. when clicking on browse (filerequest dialog), it would start browsing in that specified directory.
I'm not sure if this would work, but you could try storing an initial path in the box (State), and get rid of the text when the page is shown (with SendMessage ... "STR:").
-Stu
-Stu
deguix, IMHO you should stop taking feature requests for a while and concentrate on stabilizing and documenting what you currently have.
I want to add support for InstallOptionsEx to EclipseNSIS, but I am hesitant because IOEx is in constant flux.
I want to add support for InstallOptionsEx to EclipseNSIS, but I am hesitant because IOEx is in constant flux.
No problem. I'll try to fix the maximum amount of bugs that appear. There aren't many though (except in docs). But I generally find more because I have to test most of the stuff; bugs generally aren't reported to me, even with the huge amount of people that read this thread.
Maybe I should put this plug-in somewhere like sourceforge. It will probably be more organized, and will support some direct feedback without cluttering the forums more than they are already... a dump of this would probably take many days.
Could I ask you a question? Do you think the plug-in is confusing to use (except for the documentation which needs adjustments)?
Maybe I should put this plug-in somewhere like sourceforge. It will probably be more organized, and will support some direct feedback without cluttering the forums more than they are already... a dump of this would probably take many days.
would it be possible to add a feature, which allows me to specify a default directory for contols (i.e. filerequest).Well, okay... what should I do then? Put it in "ListItems" or to make the plug-in to select the path from the file path automatically by using an extra flag? If "MULTISELECT" flag is specified, would the path of the first file be used if you want me to add the extra flag feature?
let's say the user has to specify a file in on of my ioex pages and that it's most likely that this file is stored in a specific directory (i.e. my documents). i would love to have the option to specify this directory, when the installer initialises. when clicking on browse (filerequest dialog), it would start browsing in that specified directory.
Could I ask you a question? Do you think the plug-in is confusing to use (except for the documentation which needs adjustments)?
I think moving the project to SourceForge would be a great idea. It will add more structure to your development, with clearly defined trackers for bugs, feature requests, etc. You can better manage what you are doing. Plus you get all the associated stuff for free (e.g., source control, release mechanism, etc.). Also, you may be able to recruit other developers to help out with it.
The plugin can be overwhelming, I feel, for a new user since it has sooo much stuff in it (given that the documentation is not synced up yet).
The plugin can be overwhelming, I feel, for a new user since it has sooo much stuff in it (given that the documentation is not synced up yet).
Next version, 2.4.2 beta 6, is going to have removed the GPL code for allowing more types of images. Does anyone have any suggestions for a free code (no GPL, no commercial licenses) replacing the current GPL code for this? If yes, then I can include it readly. Also, part of it is not considered GPL because it was taken from another source, so I can modify it to not be a copy anymore. Thus, general support for .jpg, .jpge, and .gif image types is still on IOEx.
I'll only talk about the other modifications when I release it.
I'll only talk about the other modifications when I release it.
Just for reference, I think the last message on the GPL found its basis at :
WINAMP.COM | Forums > Developer Center > NSIS Discussion > Changing the form
-----
GPL: http://www.gnu.org/copyleft/gpl.html
I don't mind the GPL so much myself - I admire its premise, actually.
The problem, at least to me, is that I've never found it quite clear what happens when you include a -compiled- piece of GPL code in your product or distribution.
I.e. if somebody were to use InstallOptionsEx with the GPL code in there, I can only imagine that it would consitute one of the two basic things..
- you're distributing a GPL'd product
- you're dynamically linking to a lib (the dll is 'separate' in the installer and gets extracted - so it doesn't become an integral part to the installer code itself)
So as far as I can tell - using InstallOptionsEx with the GPL'd code in the binary doesn't mean your entire installer becomes GPL - much less so any other software you may be installing with the installer.
However, it does leave questions such as :
- do I need to include the GPL text with my installer ?
- do I need to display that GPL code is being used ?
- do I need to give users access to the source code of InstallOptionsEx if they were to ask for it ? and/or include it ?
etc.
I believe the answer to all the above is 'yes', but I'm not a lawyer 🙂
-----
Lastly, separate of the GPL, InstallOptionsEx has its own licensing requirement;
"3. This notice may not be removed or altered from any distribution."
Similar questions - where, when and how should said notice be included ? Or does it apply to distributions of the InstallOptionsEx -package- only ? i.e. doesn't apply if you're simply using the plugin in your installer.
Thanks in advance 🙂
WINAMP.COM | Forums > Developer Center > NSIS Discussion > Changing the form
Are you a developer who uses NSIS to distribute your application? Are you a Winamp plug-in developer who wants to use NSIS to distribute your plug-in? Have suggestions for other people like you? This is the place.
-----
GPL: http://www.gnu.org/copyleft/gpl.html
I don't mind the GPL so much myself - I admire its premise, actually.
The problem, at least to me, is that I've never found it quite clear what happens when you include a -compiled- piece of GPL code in your product or distribution.
I.e. if somebody were to use InstallOptionsEx with the GPL code in there, I can only imagine that it would consitute one of the two basic things..
- you're distributing a GPL'd product
- you're dynamically linking to a lib (the dll is 'separate' in the installer and gets extracted - so it doesn't become an integral part to the installer code itself)
So as far as I can tell - using InstallOptionsEx with the GPL'd code in the binary doesn't mean your entire installer becomes GPL - much less so any other software you may be installing with the installer.
However, it does leave questions such as :
- do I need to include the GPL text with my installer ?
- do I need to display that GPL code is being used ?
- do I need to give users access to the source code of InstallOptionsEx if they were to ask for it ? and/or include it ?
etc.
I believe the answer to all the above is 'yes', but I'm not a lawyer 🙂
-----
Lastly, separate of the GPL, InstallOptionsEx has its own licensing requirement;
"3. This notice may not be removed or altered from any distribution."
Similar questions - where, when and how should said notice be included ? Or does it apply to distributions of the InstallOptionsEx -package- only ? i.e. doesn't apply if you're simply using the plugin in your installer.
Thanks in advance 🙂
The maximum thing needed is to inform the user about IOEx and where it's source code is when there is GPL code, which is already not good for me.
Lastly, separate of the GPL, InstallOptionsEx has its own licensing requirement;Well, this part shows the reasoning of this:
"3. This notice may not be removed or altered from any distribution."
Similar questions - where, when and how should said notice be included ? Or does it apply to distributions of the InstallOptionsEx -package- only ? i.e. doesn't apply if you're simply using the plugin in your installer.
[...] to alter it and redistribute it freely, subject to the following restrictionsThis "and" shows that it applies only when altering the code and redistributing it.
Ahhh okay... I'm not a lawyer, etc. but I think phrased that way it's actually two separate terms... e.g.
"to alter it, subject to the following restrictions"
"to redistribute it freely, subject to the following restrictions"'
The intended meaning, I *think*, would be phrased as "to alter and redistribute it freely, subject to the following restrictions"
Regardless though - cool, thanks for clarification 🙂
"to alter it, subject to the following restrictions"
"to redistribute it freely, subject to the following restrictions"'
The intended meaning, I *think*, would be phrased as "to alter and redistribute it freely, subject to the following restrictions"
Regardless though - cool, thanks for clarification 🙂
I just forgot to say that it won't have the features I planned for it, it will be just a quick version to fix the GPL issue and some other fixes I picked up. Also, as NSIS 2.11 was released with InstallOptions version 2.44, it's going to be called "IOEx 2.44 beta 1" (Next time I should consider how I put versions on my projects, now I can only go forth to version 3 or to make patches for IO with IOEx code).
InstallOptionsEx 2.4.4 beta 1 - DLL + Source
New version released. No much was changed, as expected. See the full list of changes for this version:
New version released. No much was changed, as expected. See the full list of changes for this version:
- Removed GPL'd code from the plug-in. Removed support for GDI+, which in turn, removed newer systems support of .png, .tiff, and .emf files.
- Added support for the key "F2" on TreeView and ListView controls.
- Fixed the selection of the last item with the "End" key in a ListView control without the CHECKBOXES flag and without using LargeImageList INI key.
- Fixed: When StateImageList points to an invalid file, it still applies the CHECKBOXES flag normally.
- Fixed: When a label was not changed in TreeView or ListView controls that use the EDITLABELS flags, it was emptied.
BTW this plug-in supports png and other formats without GDI 😉
May be problems with some complex variants of tiff formats on systems with old IEs (or may be not, I cannot remember this precisely in the sunday evening) 🙂
May be problems with some complex variants of tiff formats on systems with old IEs (or may be not, I cannot remember this precisely in the sunday evening) 🙂
Yes, I saw your plug-in source code one time, but I didn't got the inclusion to work. I might try to do that again later, or you could submit a patch, if you can read a big amount of code... Just search for IMAGE_TYPE_OLE and you can find the current OLE implementation I have. I think your code is somewhat based on that.