SuperPat
9th February 2007 11:41 UTC

InstallOptionsEx 2.4.5 beta 1 unofficial Released
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
14th February 2007 07:07 UTC

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
14th February 2007 07:37 UTC

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
14th February 2007 17:25 UTC

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

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;
}

#define Notification(ID, CODE) \
  case CODE: \
  { \
    if(pField->nNotify & ID) \
    { \
       g_aNotifyQueueTemp->iNotifyId = ID; \
       goto notify; \
    } \
    break; \
  }

Sheik
14th February 2007 18:50 UTC

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
14th February 2007 19:48 UTC

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
14th February 2007 20:06 UTC

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
15th February 2007 08:41 UTC

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
15th February 2007 13:58 UTC

@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
16th February 2007 22:23 UTC

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
18th February 2007 04:32 UTC

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
18th February 2007 15:11 UTC

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
19th February 2007 03:32 UTC

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
19th February 2007 13:10 UTC

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
19th February 2007 18:34 UTC

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
20th February 2007 09:49 UTC

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

Sheik
20th February 2007 15:54 UTC

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 fuDlgCode:DLGC_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
20th February 2007 15:55 UTC

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

Sheik
20th February 2007 16:38 UTC

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
20th February 2007 19:59 UTC

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
20th February 2007 20:13 UTC

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
22nd February 2007 12:59 UTC

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
22nd February 2007 16:45 UTC

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
22nd February 2007 21:13 UTC

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
24th February 2007 13:35 UTC

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
24th February 2007 21:16 UTC

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
25th February 2007 12:35 UTC

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
26th February 2007 16:40 UTC

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
26th February 2007 18:14 UTC

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
27th February 2007 19:17 UTC

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
27th February 2007 20:32 UTC

Yup, I see exactly what you see.

kichik
27th February 2007 20:49 UTC

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

SuperPat
27th February 2007 21:32 UTC

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
28th February 2007 00:56 UTC

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
28th February 2007 17:20 UTC

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
28th February 2007 17:23 UTC

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
28th February 2007 21:40 UTC

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
4th March 2007 04:37 UTC

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

Scott

SuperPat
4th March 2007 15:28 UTC

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
4th March 2007 17:03 UTC

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