InstallOptionsEx 2.4.5 beta 1 unofficial Released

[SuperPat]

Hello,

I have released an unofficial version (2.4.5 beta 1) of the InstallOptionEx plugin.

This version consists mainly of the correction of bugs (in particular on RichText and TreeView controls) and the update with lastest CVS version of InstallOption.

Changelog:
# Compiled with VisualStudio 2005. Fixed warnings and use the secure fopen_s function instead of fopen.
# Fixed: The selection of a subitem in TreeView returned only the root item.
# Fixed: Empty items appeared sometimes in TreeView.
# Fixed: RichText files were not loaded if they were situated in a directory starting with "n", "r" or "t".
# Fixed: Richtext fields were selected and scrolled down even if they used the READONLY and MULTILINE flags.
# RichText files are not rewritten any more in the leave function if the READONLY flag is used.
# Added: VSCROLL flag support for RichText controls.
# Added: ONCLICK flag by default on Notify key if not specified for Link controls for IO compatibility.
# Added: HWND entry to the INI file to avoid messy calculations of the correct control id.
# Added: WS_EX_LEFTSCROLLBAR in RTL mode (IO bug #1283528).
# Added: FOCUS flag for setting focus to a control other than the first (IO patch #1634704).


Could you help me to correct the few problems which remain?
- If we change the background color of a Link control to transparent, the background color become white...
- We cannot change the text and background colors of a GroupBox control, it remains color of Windows....
See the NSISDIR\Example\InstallOptionsEx\test.nsi script to see this problems.

Post your patchs/bugs/remarks in this topic, Tanks.

Download InstallOptionsEx

[Sheik]

Hi SuperPat, all,

Not sure if this is causing all your problems or not,
but I have discovered quite a big bug in the Notify parsing in InstallOptionsEx...

I was running into a problem when trying to set 2 Notify options for a ListBox.

For example:

Notify=ONSELCHANGE|ONDBLCLICK

Not only did this not work, but it actually STOPPED delivering Notify's for that Box completely!

I could do one or the other, but not both.

Just looking at the code, I see the problem...

For the ListBox parser:

case FIELD_LISTBOX:
{
switch(pField->nNotify)
{
Notification(NOTIFY_CONTROL_ONSELCHANGE, CBN_SELCHANGE);
Notification(NOTIFY_CONTROL_ONDBLCLICK, CBN_DBLCLK);
Notification(NOTIFY_CONTROL_ONSETFOCUS, CBN_SETFOCUS);
Notification(NOTIFY_CONTROL_ONKILLFOCUS, CBN_KILLFOCUS);
}
break;
}

This code will work fine as long as only *1* Notify option is set, but if you set 2 or more, the "switch" code is simply wrong!

The values for multiple options are bit Or'ed together, thus the case: statements will *NOT* trigger.

The Notification() #define really makes the problem hard to find and debug... It took me awhile to find it.

The problem exists on all Notify's for all the various types of pages/dialogs, so maybe its causing you problems as well...

Its too late tonight for me to really fix it up, I gotta get some sleep.

BTW, When is your beta 2 coming out of UMUI?

Scott

[Sheik]

BTW,

Here is the "fixed" code for the ListBox.

Its not particularly elegant, and we could probably clean it up behind some defines, but I am too tired to do that tonight.

Anywhere, here is the "fixed" code:

if (codeNotify == CBN_SELCHANGE) {
if(pField->nNotify & NOTIFY_CONTROL_ONSELCHANGE) {
g_aNotifyQueueTemp->iNotifyId = NOTIFY_CONTROL_ONSELCHANGE;
goto notify;
}
}
else if (codeNotify == CBN_DBLCLK) {
if(pField->nNotify & NOTIFY_CONTROL_ONDBLCLICK) {
g_aNotifyQueueTemp->iNotifyId = NOTIFY_CONTROL_ONDBLCLICK;
goto notify;
}
}
else if (codeNotify == CBN_SETFOCUS) {
if(pField->nNotify & NOTIFY_CONTROL_ONSETFOCUS) {
g_aNotifyQueueTemp->iNotifyId = NOTIFY_CONTROL_ONSETFOCUS;
goto notify;
}
}
else if (codeNotify == CBN_KILLFOCUS) {
if(pField->nNotify & NOTIFY_CONTROL_ONKILLFOCUS) {
g_aNotifyQueueTemp->iNotifyId = NOTIFY_CONTROL_ONKILLFOCUS;
goto notify;
}
}

[SuperPat]

Hello,

Thank you to have reported this problem,
Currently, I have not tested it but if you replace the code by this one, you should obtain the same result as your code

code:
case FIELD_LISTBOX:

{

  switch(codeNotify)

  {

    Notification(NOTIFY_CONTROL_ONSELCHANGE, CBN_SELCHANGE);

    Notification(NOTIFY_CONTROL_ONDBLCLICK, CBN_DBLCLK);

    Notification(NOTIFY_CONTROL_ONSETFOCUS, CBN_SETFOCUS);

    Notification(NOTIFY_CONTROL_ONKILLFOCUS, CBN_KILLFOCUS);

  }

  break;

}

code:
#define Notification(ID, CODE) \

  case CODE: \

  { \

    if(pField->nNotify & ID) \

    { \

       g_aNotifyQueueTemp->iNotifyId = ID; \

       goto notify; \

    } \

    break; \

  }

I will fix it this week end an released a new development build.

Moreover, I will remove this horrible goto!

[Sheik]

Hi SuperPat,

Ah yes, that should work as well, and cleans up all the various NOTIFY's for *all* the dialogs all at once!

Last night, I was worried about changing Notification(), as I only have started working on the code since last night.
I didn't know what ramifications changing that #define might have on the rest of the code!

Also,
I am trying to use your code dump, and I don't have "fopen_s", I am assuming that must in a new lib that ships with VS 2005?

Scott

[Sheik]

BTW,

The 2 problems you still have pending...

Are you sure they are InstallOptionEx problems?

You are using SetCtlColors, which is a function provided by the base NSIS Installer, right?

Looking at InstallOptionEx, it sure doesn't look like it does much deaking with Group Boxes...

Maybe you can avoid using SetCtlColors, and instead just call the needed things directly by using System/calls directly into the OS...

Scott

[Sheik]

I found this thread from google, not sure if their comment is still valid, (its from 98!)

http://groups.google.com/group/comp....b14167916e8fa9

The post and response:

Dexter Sinister wrote in message <363C943C.C21F2...@lotus.com>...
>I have a property page object with a groupbox on it. I want to be able
>to set the background color of the groupbox on the fly. The point of
>this is to output examples of text settings (font, foreground color,
>background color) in the groupbox.

>I cannot figure out how to set the background color of the entire
>groupbox. Any hints would be very much appreciated.


Groupbox controls don't HAVE a background colour - they are just a "frame"
with a transparent interior. One solution would be to put an empty static
text control on the dialog, then put the groupbox on top of it. Set the
colour of the static control in the usual way.

[SuperPat]

But the groupbox colors can be set with the original InstallOption fine. it's this that I don't understand...

The fopen_s function is appeared with Visual Studio 2005

[SuperPat]

@Sheik
I am sure they are InstallOptionEx problems because the SetCtlColors work fine with the original InstallOption GroupBox and Link controls.

Thus, It must be possible to make it work with IOEx.

[SuperPat]

This is the last development version of the unofficial InstallOptionsEx plugin

Changelog (2.4.5 beta 2 14/Feb/2007):
Fixed: If more than one notify flags is used for a control, any action was notified.
A goto was removed.

Download as zip
Download as exe

[Sheik]

Hi SuperPat,

I will take a look deeper into your problem.

Couple things about the source...

1) Using Visual Studio 6, I get this error:
c:\nsis\installoptionsex2.4.5b2_2007-02-14\contrib\installoptionsex\installeroptions.cpp(2120) : error C2374: 'nIdx' : redefinition; multiple initialization
c:\nsis\installoptionsex2.4.5b2_2007-02-14\contrib\installoptionsex\installeroptions.cpp(252) : see declaration of 'nIdx'

I just went and cleaned it up by changing it to nIdx2 on line 2120, as well as in that for() loop.

2) This one is minor, but it sure would be nice. =)
I don't seem to have COLOR_MENUHILIGHT defined in my headers, so I tacked this in the .h file right below
the #ifndef USER_TIMER_MINIMUM section:

#ifndef COLOR_MENUHILIGHT
#define COLOR_MENUHILIGHT 29
#endif

Finally, the fopen_s()...
I am wondering if you could ifdef that one by having it as a regular fopen() for anyone using anything less than VS 2005...
If not, no biggie, I just keep having to change it back to fopen() all the time. =)

Scott

[SuperPat]

New development version:

Changelog (2.4.5 beta 2 18/Feb/2007):
Fixed: VisualStudio 6 errors and warning:
_ multiple initialization of the nIdx variable;
_ definition of COLOR_MENUHILIGHT if it doesn't exist in your headers;
_ by default, the fopen function is used instead of fopen_s except if you define USE_FOPEN_S in the compilation options (for VisualStudio 2005 only).

Download as zip
Download as exe

[Sheik]

Hi SuperPat,

Thanks for the changes, the compile goes much smoother now. =)

After spending a considerable amount of time trying to track down your GroupBox problem, I am getting pretty convinced that it can't be something in the "GroupBox" handling, or lack of handling...

I am now starting to think that maybe its parent window is causing the problem.

What have you found in your debugging?

[SuperPat]

I have also spending a lot of time but I never have succeeds found the problem.
All what I have succeeds to obtain, it is a black background on the groupbox and link.
For the link controls, I tested by looking how was made the checkbox and radiobutton but without more success…

We may be compare the code of IOEx with the original InstallOption.

[Sheik]

Hi SuperPat,
Ya, I am trying to figure out what the difference is between IO and IOEx...
Nothing really sticks out.

I am thinking we might be able to use "Spy++" to try to capture the various messages sent to these WIndows, and maybe catch the message that we seem to be missing...

What do you think?

[SuperPat]

Good idea, but for my part, I don't know how to do this.

[Sheik]

Hi SuperPat,

Spy++ ships with VS 6, and presumably VS 2005 as well.

You run it, and then tell it what "Window" to watch,
by dragging the "pointer" to the window we care about.

In this case, I drag it to the window with the text of "This is a group box with a..."
(Class of a Button).
(Window 20600 for this run)

Here are the messages I get when I "hide" the window, then bring the window back to the foreground, which should cause it to redraw everything.

<00001> 00020600 S ..WM_GETDLGCODE
<00002> 00020600 R ..WM_GETDLGCODE fuDlgCodeLGC_STATIC
<00003> 00020600 P WM_PAINT hdc:00000000
<00004> 00020600 S .WM_NCPAINT hrgn:00000001
<00005> 00020600 R .WM_NCPAINT
<00006> 00020600 S .WM_ERASEBKGND hdc:820116CD
<00007> 00020600 R .WM_ERASEBKGND fErased:True

Scott

[Sheik]

Odd, we got a smiley face in the output.
Its "DLGC_STATIC" in there.

[Sheik]

Hi SuperPat.

I have found/fixed your problem!

Go to ReadSettings().

Look for this code:
// Remove FLAG_CUSTOMDRAW_TEMP flag only when the user
// specifies any of the color commands.
switch(pField->nType)
{
case FIELD_LABEL:
case FIELD_LINK:
case FIELD_TEXT:
case FIELD_LISTBOX:
case FIELD_COMBOBOX:
{
pField->nFlags |= FLAG_CUSTOMDRAW_TEMP;
break;
}
}

If we add:
case FIELD_GROUPBOX:

To the switch, this fixes the problem.

Hopefully this fixes most (all?) of your problems, so that a new version of UMUI can get released!

(I am *really* looking forward to it!)

Scott

[Sheik]

Hi SuperPat,

And another fix for your "Transparent" Link problem.

(ie, the one where if you have transparent on, it displays the background of the link in white)

The code is just not taking into account that the transparent mode is already on.

Specifically, go to:

if (lpdis->itemAction & ODA_DRAWENTIRE)

To this line:
// Draw Background on the whole control
if(crBgColor != 0xFFFFFFFF)

And change it to be:

// Draw Background on the whole control
if(crBgColor != 0xFFFFFFFF && GetBkMode(lpdis->hDC) != TRANSPARENT) {

Scott

[Sheik]

And finally,

After that change, the "link" text has a weird "white" shadow effect purposely put around the characters in the link.
This is just plain strange looking, and I suspect it should NOT be done when in TRANSPARENT mode...

So this code:

if(crTxtShwColor != 0xFFFFFFFF) {


// Draw Shadow Text
++rc.left;
++rc.right;
++rc.top;
++rc.bottom;
SetTextColor(lpdis->hDC, crTxtShwColor);

DrawText(lpdis->hDC, pField->pszText, -1, &rc, DT_EXPANDTABS | DT_WORDBREAK | (pField->nTxtAlign == ALIGN_TEXT_LEFT ? DT_LEFT : 0) | (pField->nTxtAlign == ALIGN_TEXT_CENTER ? DT_CENTER : 0) | (pField->nTxtAlign == ALIGN_TEXT_RIGHT ? DT_RIGHT : 0));

// Draw Normal Text
--rc.left;
--rc.right;
--rc.top;
--rc.bottom;
}

Probably should be changed to be like
if(crTxtShwColor != 0xFFFFFFFF && GetBkMode(lpdis->hDC) != TRANSPARENT) {

Scott

[SuperPat]

New development version:

Changelog (2.4.5 beta 2 22/Feb/2007):
Fixed: Groupbox and Link controls colors problems (thanks Sheik).


I have found an other problem with button using the OPEN_FILEREQUEST, SAVE_FILEREQUEST, DIRREQUEST... flags, when I click on these buttons, it does not occur anything.
See the the test.ini example.


Download as zip
Download as exe

[Sheik]

Thanks.

These are the messages being sent to the button when clicked (from Spy++):

<00201> 00020B66 S .WM_MOUSEACTIVATE hwndTopLevel:01970ABA nHittest:HTCLIENT uMsg:WM_LBUTTONDOWN
<00202> 00020B66 R .WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE
<00203> 00020B66 S .WM_SETCURSOR hwnd:00020B66 nHittest:HTCLIENT wMouseMsg:WM_LBUTTONDOWN
<00204> 00020B66 R .WM_SETCURSOR fHaltProcessing:False
<00205> 00020B66 P WM_LBUTTONDBLCLK fwKeys:MK_LBUTTON xPos:12 yPos:12
<00206> 00020B66 S .WM_NCHITTEST xPos:924 yPos:376
<00207> 00020B66 R .WM_NCHITTEST nHittest:HTCLIENT
<00208> 00020B66 S .WM_SETCURSOR hwnd:00020B66 nHittest:HTCLIENT wMouseMsg:WM_LBUTTONUP
<00209> 00020B66 R .WM_SETCURSOR fHaltProcessing:False

[Sheik]

Hi SuperPat,

I think you forgot to set up a NOTIFY:
Put this in your .ini file for each of those BUTTON controls:

Notify=ONCLICK

This isn't ideal either tho, cuz it will still call into our "validate" function, which we really don't want.

You probably want to muck around with having the
Notify=ONCLICK in the .ini file,
but process it differently in the dll.

Scott

[SuperPat]

Hello,

Indeed, when we add the Notify=ONCLICK on the button field, the dialog appear, but I don't want that it calls the leave function because it is not very clean.

This is why it would really have to be modified the DLL so that it do not need Notify=ONCLICK to show File/Dir.. dialogs

An other problem found with the FileDialog:
The filter key contain
Filter=Poop Files|*.poop|All files|*.*
The filter is constructed by putting pairs of entries together, each item separated by a | character. The first value in each pair is the text to display for the filter. The second value is the pattern to use to match files.
But it doesn't work, I have only one entry and his name is Poop Files|*.poop|All files|*.*
Obviously, It does not have succeeds in cutting out the pairs...

[SuperPat]

New development version:

Changelog (2.4.5 beta 2 24/Feb/2007):
Fixed: A filter key problem for button using the OPEN_FILEREQUEST and the SAVE_FILEREQUEST flags, it did not cut the string in items.


Download as zip
Download as exe

[SuperPat]

New development version:

Changelog (2.4.5 beta 2 25/Feb/2007):
Fixed: The Notify=ONCLICK is not necessary any more for a boutton using OPEN_FILEREQUEST, SAVE_FILEREQUEST, DIRREQUEST, FONTREQUEST and COLORREQUEST flags to show the dialog. Thus the leave function is not called any more unnecessarily.


Download as zip
Download as exe

[Sheik]

Thanks SuperPat,

Are there any more outstanding bugs we need to find/fix?
Or are you finally good to go?

(All my outstanding problems have been resolved)

Scott

[SuperPat]

New development version:

Changelog (2.4.5 beta 2 26/Feb/2007):
Fixed: The Notify=ONCLICK and Notify=ONDBLCLICK didn't work with the Link control.
Link an Button can now be used in the same way.
The Notify=ONCLICK is not necessary any more for a link or a button using OPEN_FILEREQUEST, SAVE_FILEREQUEST, DIRREQUEST, FONTREQUEST and COLORREQUEST flags to show the dialog. As for if the State key containing something to be executed or opened. Thus the leave function is not called any more unnecessarily.
Documentation updated.


Download as zip
Download as exe


Sheik, I did not find any additional bugs for the moment

[SuperPat]

I have found 2 bugs in InstallOptionEx:

First:
Transparent Icons are not transparent in the page...
Second:
Button are not drawn if I use my SkinnedButton plugin...

whereas that work very well with InstallOptions


See the test2.nsi Example


Download as zip
Download as exe


Sheik, can you see this?

[Sheik]

Yup, I see exactly what you see.

[kichik]

With so many changes, wouldn't it be nicer to arrange it under http://sf.net/projects/nsis-ioex?

[SuperPat]

False translation, I wanted to say:
Can you look at that?

I have found a third problem with DIRREQUEST Dialog:
When you click on it, It doesn't go to the directory indicated in the Text control.

I have reuploaded the lastest dev version with a little fix (but we must check it):
Sometime, the plugin crach when it tries to show the DIRREQUEST Dialog.

[Sheik]

Hi SuperPat,

This one is pretty tough...

I can "capture" the drawing by going to:

case WM_DRAWITEM:

And changing:

if(pField->nType == FIELD_LABEL || pField->nType == FIELD_LINK) {

to:

if(pField->nType == FIELD_LABEL || pField->nType == FIELD_LINK || pField->nType == FIELD_BUTTON) {

But it doesn't really draw it right...
But we do get "..." which is more than we got before...

Hopefully this can help you track it down more.

[Sheik]

Hi kichik,

Yes.
Quite honestly, I am hoping this thread dies soon, that means all the bugs that SuperPat and I are finding are fixed. =)

We aren't actually doing any new developement on IoEx...
(At least, I sure am not).

We are just trying to clean up most of the bugs.
Once thats done, this thread will go away.

Scott

[Sheik]

SuperPat,
BTW, there is obviously an interaction problem with it and your skinnedbutton plugin.
If I yank the skinnedbutton from your test, the buttons get drawn right.
Maybe the fix here is as simple as sending a message to the skinnedbutton to redraw itself...
(This obviously should be happening automagically, but maybe thats the bug, that IOEX isn't sending it.)

Scott

[Sheik]

SuperPat,
Another test I did.
Get rid of all your color changing stuff from the test2 script.

Even with doing that, the 2 pushbuttons don't show up.

The only way I can get them to show up, is if I get rid of
the skinnedbutton calls, so that the regular buttons get used.

Scott

[Sheik]

Hi SuperPat,
Any luck or progress fixing the current set of bugs?

Scott

[SuperPat]

not nothing alas...

And you for the problem of the transparent icons on a coloured background where the SetCtlColors function doesn't have any effects?

[kichik]

Originally posted by Sheik
Hi kichik,

Yes.
Quite honestly, I am hoping this thread dies soon, that means all the bugs that SuperPat and I are finding are fixed. =)

We aren't actually doing any new developement on IoEx...
(At least, I sure am not).

We are just trying to clean up most of the bugs.
Once thats done, this thread will go away.

Scott

That too should be on the project page. It's the centralized place for ioex development. I'm sure deguix will not mind giving you access so you can upload the fixes there as well.