InstallOptionsEx 2.4.2 beta 3 post-build 3 - DLL
Another build, and more fixes and additions:
- Added MULTISELECT for ListView controls (made single selection default in this case).
- Fixed the return of State and ListItems INI values for Link and Button controls with COLORREQUEST flag.
InstallOptionsEx
368 posts
I have a question regarding the Beta 3 Post build 3:
I have the following Ini Code:
I have the following Ini Code:
I use this 2 Controls to display which file the user had selected. In your Docs you're saying that the Reffield command is input only and that the output of the Filerequest control is the state value of that control. So my question is: Is it still possible that the output is given to another control?
[Field 17]
Type=Text
Left=20
Right=120
Top=160
Bottom=175
State=
Flags=Disabled
[Field 18]
Type=Button
Left=130
Right=150
Top=160
Bottom=175
RefField=17
State=
Text=...
Flags=OPEN_FILEREQUEST
NOTIFY=ONCLICK
Filter=All Files|*.*
ToolTipIcon=INFO
ToolTipTitle=Messagetext
ToolTipText=Choose a File to add to your Mail
ToolTipFlags=BALLOON
ToolTipTxtColor=0x000000
ToolTipBgColor=0xE1FFFF
ToolTipMaxWidth=300
It's RefFields, sorry 'bout that.
Now i works - thanks
ININININ
I still think my Tab idea is the best. It make the hole thing more structured as you can keep the fields for the different tabs in separate Ini files. Nothing more would be required really. You just have to read more than one INI in your page leave callback function.
I still think my Tab idea is the best. It make the hole thing more structured as you can keep the fields for the different tabs in separate Ini files. Nothing more would be required really. You just have to read more than one INI in your page leave callback function.
Ok? How about the control IDs of the fields when importing other INI's, would fields have to start at 1 also in those INI's?
1) If yes: This would need extra handling for additional types of control ID's (starting at 1300 for example), a variable containing the groups of tabs that occupy certain ID groups, and a defined limitation of number of controls a page can have. Also, there is the nesting of tabs inside others. What would be the ID's of the controls inside this tab control nested in another? They would have to be in the same ID group, so the division in the number of controls the group could have is halved, and thus the limitation could make the nesting of 5 tab controls, one inside another, to reduce considerably to just 1 control (if the actual limit of controls is 100). I'm not even counting how many INI files you would need to create for this nesting, because that would be in an huge number.
2) If no: What's the reason for creating separated pages then? You'll be limited to use different ID's for the controls anyways. It's a lot better having only 1 INI to worry about. If you need to be in separate pages, why not concatenate the INI files at run-time? That would be easier than adding more KB's to your favorite plugin for nothing. People don't usually use this feature. This feature is not even GUI related.
So, does everyone agree that my idea is better for the future of IOEx? 🙄
1) If yes: This would need extra handling for additional types of control ID's (starting at 1300 for example), a variable containing the groups of tabs that occupy certain ID groups, and a defined limitation of number of controls a page can have. Also, there is the nesting of tabs inside others. What would be the ID's of the controls inside this tab control nested in another? They would have to be in the same ID group, so the division in the number of controls the group could have is halved, and thus the limitation could make the nesting of 5 tab controls, one inside another, to reduce considerably to just 1 control (if the actual limit of controls is 100). I'm not even counting how many INI files you would need to create for this nesting, because that would be in an huge number.
2) If no: What's the reason for creating separated pages then? You'll be limited to use different ID's for the controls anyways. It's a lot better having only 1 INI to worry about. If you need to be in separate pages, why not concatenate the INI files at run-time? That would be easier than adding more KB's to your favorite plugin for nothing. People don't usually use this feature. This feature is not even GUI related.
So, does everyone agree that my idea is better for the future of IOEx? 🙄
I think it's fine. It'll be easier to manage everything in one INI file as well I think.
-Stu
-Stu
So you mean that you want a very huge INI file?
And the controls that are on the tabs are hosted in their own childdialog anyway. You can't just place all contols on one dialog and then do show/hide of controls depending on what tab is selected. No real applications does this. They create separate dialogs for each tab and then swap between these page dialogs (moves active page dialog up z order and hides non-active page dialogs).
Thus you can have separate INI files and you don't have to worry about control IDs as they are unique within each dialog anyway.
And the controls that are on the tabs are hosted in their own childdialog anyway. You can't just place all contols on one dialog and then do show/hide of controls depending on what tab is selected. No real applications does this. They create separate dialogs for each tab and then swap between these page dialogs (moves active page dialog up z order and hides non-active page dialogs).
Thus you can have separate INI files and you don't have to worry about control IDs as they are unique within each dialog anyway.
Ok, you have the reason in saying that controls have unique ID's and it does the basic job of Tab controls. 🙁 I was not studying over this type of control yet (didn't read SDK). I was more thinking on fixing bugs and implementing missing features first, and just then implement controls.
I still don't think I can do it for next versions, because, as I said, it's still a little difficult to manage INI files like that (independent window messages handling and other stuff).
For this, IOEx would need the support to be used for multiple dialogs, and this is a major TODO. If I can get this going, I can also get the creation of independent dialogs which is also a major TODO. However, I need to work first on remodelating the source code for the implementation of external controls (major TODO). As I implemented almost all the controls that don't need the major TODO's (except for HotKey, ScrollBar, ToolBar, StatusBar) IOEx is getting closer and closer from major release.
I still don't think I can do it for next versions, because, as I said, it's still a little difficult to manage INI files like that (independent window messages handling and other stuff).
For this, IOEx would need the support to be used for multiple dialogs, and this is a major TODO. If I can get this going, I can also get the creation of independent dialogs which is also a major TODO. However, I need to work first on remodelating the source code for the implementation of external controls (major TODO). As I implemented almost all the controls that don't need the major TODO's (except for HotKey, ScrollBar, ToolBar, StatusBar) IOEx is getting closer and closer from major release.
I don't think you should work this much on IOEx. The original purpose of IOEx was to bring more control classes to the playground and not be a complete user-interface tool for NSIS. I don't think we need that much in a installer anyway. If NSIS evolved into being a complete apllication development platform, then maybe...
What I would like is an easy way in the original InstallOptions plug-in to set and retrieve listbox items without using SendMessaget and GetDlgItem functions. What about simple functions called "ListboxGetItem", "ListboxSetItem", "ListboxGetCurSel", "ListboxDeleteItem" exported by the plug-in. I hate doing extensive string manipulations on the ListItems INI key (searching for a string matching the State and splitting on "|" character. And the NSIS script language was really not intended for this heavy string processing. The end result: You can drop a listbox and have add/remove buttons so people can configure some app right in the installer (add remove some items).
What I would like is an easy way in the original InstallOptions plug-in to set and retrieve listbox items without using SendMessaget and GetDlgItem functions. What about simple functions called "ListboxGetItem", "ListboxSetItem", "ListboxGetCurSel", "ListboxDeleteItem" exported by the plug-in. I hate doing extensive string manipulations on the ListItems INI key (searching for a string matching the State and splitting on "|" character. And the NSIS script language was really not intended for this heavy string processing. The end result: You can drop a listbox and have add/remove buttons so people can configure some app right in the installer (add remove some items).
1)I don't know what's the future of NSIS, so I don't also know when I should stop developing on what I have. IOEx might be by far behind other user-interface programs, but at least there is something. If I didn't change it, then you would be stuck with IO and you would try to do it also. This also plays an experience role for me. Besides, NSIS is a really easy language to learn and with a powerful compiler that has a very low overhead and that compiles things very fast in slow computers.
2) I know, that's what I'm doing right now. I'm verifying the possibility of organizing the plugin's structure to be more object-orientated, which would allow it to easily export individual functions from the DLL. I'm trying to find what's already available (MFC), get a small part of the things I find and modify them to IOEx's ways. After this optimization I could export any type of function you need. But I'm still looking for information, so don't trust totally on what I say here.
Also, there is one more InstallOptions bug I discovered (without Ex): the text returned by a ComboBox and Text controls can be up to 2 times the actual buffer limit.
2) I know, that's what I'm doing right now. I'm verifying the possibility of organizing the plugin's structure to be more object-orientated, which would allow it to easily export individual functions from the DLL. I'm trying to find what's already available (MFC), get a small part of the things I find and modify them to IOEx's ways. After this optimization I could export any type of function you need. But I'm still looking for information, so don't trust totally on what I say here.
Also, there is one more InstallOptions bug I discovered (without Ex): the text returned by a ComboBox and Text controls can be up to 2 times the actual buffer limit.
I've always felt that NSIS would be an ideal platform for program development, but it's always lacked some really necessary controls. One thing we could also do with would be to add customised menu (ie File, Edit View etc) and maybe a status bar too.
-Stu
-Stu
Yes, of course, I'll get there. But I have no experience with menus whatsoever. What syntax would you suggest?
I think you'd have to have a Field # for each menu item and it would do NOTIFY by default. You won't need to specify the position/size attributes because it will always be put on the top, in order of Field #. E.g.
[Field 1]
Type=Menu
ListItems=Open|Save|Save As
State would be the ListItem that was selected which we can check on the Leave function.
As for sub-menus, that's something different - not sure if we could do that... in fact I doubt there would be any need to anyway. Basic menus are plenty!
-Stu
[Field 1]
Type=Menu
ListItems=Open|Save|Save As
State would be the ListItem that was selected which we can check on the Leave function.
As for sub-menus, that's something different - not sure if we could do that... in fact I doubt there would be any need to anyway. Basic menus are plenty!
-Stu
The core of NSIS currently handles the UI in such a strict way that turning it into an application programming platform requires massive changes to the core. The wizard page based system only loads plug-ins in the context of a page, and not persistent through the entire application. My NSIS Debugger plug-in creates a new thread where it handles the message queue of a separate window, but that is a different thing. You can pull off many hacks to take over the wizard dialog of NSIS (my recently posted wansis plug-in demonstrates this) but ultimately in the end it is an installer and nothing else.
That's true. But if you treated NSIS differently than a installer system, then it would go away from the goal of being NSIS in the first place. Logically, if everybody would want NSIS to turn into an independent language, it would be harder on people looking for building installers effectivelly. I would prefer NSIS to be more of a programming language, but there are others who prefer NSIS as an ideal tool for creating installers. Even though NSIS have few things big programming languages have, those languages don't have an efficient tool for creating installers like NSIS is. kichik has done a good job on equilibrating both. This equilibrium is also thanks to brainsucker for creating the System plugin.
I agree. I once tried making an installer out of visual basic but that did't work. I see NSIS as an installer system that has its perks. Such as: easy writing of INI files; creates program shortcuts easily; writes to the registry easily; you can use custom graphics; use a background gradient; can use custom made pages; etc... I could go on about it, but to stop taking up space on the server I will stop now.
I have never found such an installer system that was so easy to learn. I use HM NIS edit to edit my .nsi files. The first time I use NIS edit I went straight to the wizard so I could study the script it produced. My skills have increased dramatically. My hangman setup program is an example of my skills. I might post it on my thread "Just a thought.." just to show what could be done. 😎
I have never found such an installer system that was so easy to learn. I use HM NIS edit to edit my .nsi files. The first time I use NIS edit I went straight to the wizard so I could study the script it produced. My skills have increased dramatically. My hangman setup program is an example of my skills. I might post it on my thread "Just a thought.." just to show what could be done. 😎
InstallOptionsEx 2.4.2 beta 3 post-build 4 - DLL
Wow, I about deleted this build from my computer. Luckly there is a recycle bin which I don't clean often. I've changed these things below:
- Added ListView and TreeView controls support for TxtColor and BgColor values.
- Fixed an interminable loop when UpDown controls had a buddy control that had the ONTEXTCHANGE or ONTEXTUPDATE notification flags.
I can't promise much about beta 4. It's better to do something than be talking about it every time. Also, no more fast builds. I got tired of doing them when I have not much to offer.
Wow, I about deleted this build from my computer. Luckly there is a recycle bin which I don't clean often. I've changed these things below:
- Added ListView and TreeView controls support for TxtColor and BgColor values.
- Fixed an interminable loop when UpDown controls had a buddy control that had the ONTEXTCHANGE or ONTEXTUPDATE notification flags.
I can't promise much about beta 4. It's better to do something than be talking about it every time. Also, no more fast builds. I got tired of doing them when I have not much to offer.
Will tabs still be added someday?
-Stu
-Stu
Yes, of course. But there are a lot of suggestions pending. If you want a feature right away, why don't you help me to add what you want quickly? I'd be glad to have my work changed by someone else 🙄.
Yeah! There are a lot of people who know how to code, but which rather want to wait for others to do it instead.
Come on... make something all of you...
Come on... make something all of you...
I'm still a C++ newb and the IO source especially scares me lol
I'll have a mess around with tabs later today and see if I can implement it into IO.
-Stu
I'll have a mess around with tabs later today and see if I can implement it into IO.
-Stu
That's good to hear. I will try to fixup my wansis plug-in to support skinning of tabcontrols. Read more about it in the proper topic.
DropList Problem
Don't know if this is a bug or not, but when I try to use the DropList on Win2k, it is all congested and you can't see the list drop down. I've attached the image and here's the code:
Don't know if this is a bug or not, but when I try to use the DropList on Win2k, it is all congested and you can't see the list drop down. I've attached the image and here's the code:
Also, all of the items are there in the droplist because when the droplist has focus, I can use the keyboard.
[Field 15]
Type=Label
Text=Select Language:
Left=260
Right=315
Top=8
Bottom=18
Width=
Height=
FontHeight=8
[Field 16]
Type=DropList
ListItems=English|Japanese
State=English
Left=260
Right=350
Top=18
Bottom=
Width=
Height=
ListItemsHeight=12
Notify=ONSELCHANGE
Flags=DROPLIST
Oops, here's the image...
Set "ListItemsHeight" INI value to a number bigger than 15 (the default on the current version).
This doesn't seem to have any effect. Without ListItemsHeight, it works on XP, just not on 2k.
I misunderstood your problem. Set the "Bottom" value of your "DropList" to be big enough so that it appears correctly on Win2K (I never had Win2K, so I can't test it). Also, take out the "DROPLIST" flag. This is not needed if you're using a "DropList" type of control.
That worked, thanks!
InstallOptionsEx 2.4.2 beta 4 - DLL
This time there is some big things: new value names for Settings section that add more compatibility to IO.
This time there is some big things: new value names for Settings section that add more compatibility to IO.
- MUnit INI value name: it adds the ability to use pixels coordinates instead of the dialog units. IOEx just became compatible with InstallOptions 1 pages.
- Reimplementation of NumFields INI value name: The only thing different from IO is that it now detects the number of fields existent in the INI file automatically as default.
- Added MUnit value name for Settings section and NotifyCursor for Field # section.
- Added ListView and TreeView controls support for TxtColor and BgColor values.
- Added EDITLABELS flag for TreeView and ListView controls and MULTISELECT for ListView controls (made single selection default in this case).
- Fixed empty item names for TreeView and ListView controls.
- Fixed the return of State and ListItems INI values for Link and Button controls with COLORREQUEST flag.
- Fixed an interminable loop when UpDown controls had a buddy control that had the ONTEXTCHANGE or ONTEXTUPDATE notification flags.
- Re-added NumFields from original InstallOptions for compatibility reasons.
- Fixed the range of numbers for UpDown controls. Maximum value for MaxLen and MinLen is 2147483646 and the minimum is -2147483646. Also the default values for the two value names are 2147483646 and -2147483646, respectively.
- WinXP: 0 = ListItemsHeight + border height * 2 (control is required to show up).
- Other Versions: 0 = 0 (control doesn't show up).