InstallOptionsEx

Bugs in DirRequster ?

Could you confirm 2 bugs in InstallOptionsEx 2.4.2.b4 regarding the flag DIRREQUEST for buttons:

1) STATE will not be used as input to set the default folder of the DirRequester dialog. I know, this is not documented, but even the documented feature (the default folder will be previous selected one) does not work. REFFIELDS work, but only as documented for the output of the DirRequester. It would be nice to be able to initialize the dialog's default folder via STATE or the referenced textcontrol.

2) LISTITEMS displays a pipe character (|) at the end of the string. I can only get rid of this by appending about 700 space characters to the string.

Two hints for the documentation: you should mention that the NOTIFY-value is mandatory for a button to display a requester. I had no examples and was puzzling some hours to get it work like in 'old' InstallOptions.

In "How to use - Step 6: Return Value" you mention the return value on the stack (this is documented for "InstallOptions" as well) but in your example for Step 3 (Call the DLL - "show") you "forget" to pop the return value from the stack. Does InstallOptionsEx provide no return value anymore or did you really forget the POP (there have to be 2 POPs) ?

I am currently using NSIS 2.07.

See my custom testpage in the attachment.

1) There is actually no way to fix this without creating a new custom dialog for this occasion. The input of a folder is not accepted by the BROWSEINFO structure used by the SHBrowseForFolder. If you verify throughtly, even NSIS and InstallOptions have this problem. It always points to the "My Documents" folder first.

That default value is actually the value when you read from the INI file, not the one which appears, because you can't input a folder name to the control. So, there is no reason for saying the default value that appears, because it's the Windows default = "My Documents". But still, is better to say what appears anyways for this misunderstanding to don't happen again.

2) I'll fix that.

3) Actually, any notification will be enough to bring up the dir request dialog. I'll fix this also.

4) InstallOptions' example is also wrong on this (the example is copied from there). I'll remove the first push for it to make clear that the plug-in function has a return value.

I don't see that NSIS or InstallOptions are having problems to set a default folder for SHBrowseForFolder (I did not take a look at the sourcecode). Even Delphi calls this function and it behaves like expected. I don't know how NSIS or InstallOptions are doing this, but Delphi seems to use SendMessage to select the folder [SendMessage(Wnd,BFFM_SETSELECTION,Longint(True),Longint(PChar(TBrowseFolderDlg(Data).FolderName))); in unit BrowseDlg]. Forgive me my insisting...

Oh, I forgot to see the browse callback function, probably there is a way to select it after all. Thanks for giving me the crucial hint (BFFM_SETSELECTION). And I think the problem only happens with IOEx, because this SendMessage was already in the code... I don't like when this happens.

I'm not sure if I found a bug or not, but whenever I try to set the label or link fields (at run-time) in Japanese, the Japanese text doesn't come out right. I have all my files (nsi,nsh,ini) in Shift-JIS. I commented in here but I wasn't sure if it also applied here.

Thanks.

Can you post a screenshot about the characters appear? IOEx supports only calls ANSI functions and it doesn't support Unicode.

Unfortunately I cannot post a screenshot because of work. The characters that do appear are Japanese, but they're not the ones that are suppose to be appearing.

The weird thing, I thought, was that when I do a SetFont on the labels and links between init and show, the Japanese appears correct, but only on English WinXP running in Japanese.

Here is an example of one field from the ini file and the corresponding code that sets it in the script.

[Field 1]

Type=Link

Text=

Left=54

Right=188

Top=8

Bottom=22

Width=

Height=

Notify=ONCLICK

TxtColor=0x000000

BgColor=0xE9E8E5

NotifyCursor=HAND

LangString localizedString ${LANG_ENGLISH} "english"

LangString localizedString ${LANG_JAPANESE} "japanese"

...

WriteINIStr "$PLUGINSDIR\install_menu.ini" "Field 1" "Text" "$(localizedString)"

...

Function MenuPre

  Push $HWND

  InstallOptionsEx::initDialog /NOUNLOAD $PLUGINSDIR\install_menu.ini

  Pop $HWND ; HWND of window

  GetDlgItem $R0 $HWND 1200

  SendMessage $R0 ${WM_SETFONT} $MyFont 1

  InstallOptionsEx::show

FunctionEnd

The font is being set correctly. The langstring for japanese actually has Japanese in it. And I've saved all of my script files, ini files, etc. as Shift-JIS encoding.

Thanks for the help.

The weird thing, I thought, was that when I do a SetFont on the labels and links between init and show, the Japanese appears correct, but only on English WinXP running in Japanese.

Hmmm... this problem doesn't appear to be an IOEx issue. IOEx uses the exact font from the main window, which is from NSIS itself.

I might know what this problem really is though, SetFont sets the charset to the default ANSI charset. You should use System plug-in and call the "CreateFont" from the Windows API with the SHIFTJIS_CHARSET charset for the font to show correctly. There is a thread talking about this:

I had had the system plug-in and call to CreateFont (based from that thread) and didn't think about changing the charset. However, I was using the DEFAULT_CHARSET, which should have worked on a Japanese system, right? Anyways, I changed it to:

!define DEFAULT_CHARSET 0x01

!define SHIFTJIS_CHARSET 0x80

${If} $LANGUAGE == ${LANG_JAPANESE}

  StrCpy $CharSet ${SHIFTJIS_CHARSET}

${Else}

  StrCpy $CharSet ${DEFAULT_CHARSET}

${EndIf}

System::Call "gdi32::CreateFont(i 0, i 0, i 0, i 0, i 0, \

                i 0, i 0, i 0, i $CharSet, i ${OUT_DEFAULT_PRECIS}, \

                i ${CLIP_DEFAULT_PRECIS}, i ${DEFAULT_QUALITY}, \

                i ${DEFAULT_PITCH}, t 'Sans Serif') i .r0"

This doesn't work either. It will still change appropriately on my English WinXP system, but my Japanese WinXP system, still doesn't show correct Japanese.

Thanks.

EDIT:
Also, the title bar caption and the button I have don't change on the English WinXP (ever). Is this because of how Windows works?

Well, I just tested IO vs IOEx with only a custom page and one button. The results: IO displayed correct Japanese on Japanese machine and IOEx displayed the word "2Button" instead of Japanese text on Japanese machine.

If you need more information, just let me know.

Could you test your code with the older versions published here? This might give me enough of a hint to correct your problem. Report to me which versions of IOEx work in the Japanese computer correctly. It would be even better if you fixed IOEx from there and sent me a patch to include in the next version (which should be posted here).

can you estimate, when the "\|" escape character will be implemented?

how can i display a dollar sign ($)? I looked at the code and it seems that $$ should do it, but it doesn't. am i missing something here?

also, in void WINAPI ConvertVariables(char *str) {
p3 = getuservariable(myatoi(p1));
while(*p3) {

should check p3 before dereferencing. I can cause a crash by putting $R119 in a text label, causing p3 to be null.

ok, so i've been diving into the code and it seems the problem is the $$ is being converted twice

ln 1680
// Label Text - convert newline
pField->pszText = myGetProfileStringDup("TEXT");

is called

which calls
myGetProfileString()

which calls
ConvertVariables()

then after that returns it calls ConvertVariables() again!

also, quick workaround, to get a $
use $$$$ 🙂

I didn't have time to look through all of the IOEx code to try and figure out where the fix should go because all I needed to expand off of IO was clickable bitmaps with a hand cursor for rollover, which was a quick fix.

I did check back all the way to the 3/05 release of IOEx and that still wouldn't correctly display Japanese text. I'll keep looking back till I find something that does it correctly.

there's an edit button too

ok, so i've been diving into the code and it seems the problem is the $$ is being converted twice

I fixed this region for the next version. It was really being called twice, and I fixed other small bugs also. But first, I need to finish the implementation of RichText control.

I still think there should be only one starting escape character, not "$", but "\", because putting "$$" is probably making the text for those who use "$$" complicated... and the "\\" is already considered a "\", so I could also make "\r9" to be considered equals to $R9 in NSIS. But this is just an opinion...

I didn't have time to look through all of the IOEx code to try and figure out where the fix should go because all I needed to expand off of IO was clickable bitmaps with a hand cursor for rollover, which was a quick fix.

Did you try NotifyCursor?

The other things that I added (yes added) in the next version are:
- the combination of all image controls into just one control called "Image" (even "Animation" control got in, because it shows animation of images without sound).
- added new image types using OLE and others using GDI+.
- adjustment of the size of all buffers ("BufferSize" value name for "Settings" section), which made easier to discover fixes related to memory allocation/destruction (like the two ConvertVariables one).

Did you try NotifyCursor?

Yes, but I HAD to have Japanese text working and IOEx wasn't supporting Japanese, which was why I had to revert back to IO and modify it to my needs. I'll try and figure out why (when I have time but I had a deadline...).

That's why it's said IOEx is a beta... until I'm satisfied with the features. That is, not really soon...

should check p3 before dereferencing. I can cause a crash by putting $R119 in a text label, causing p3 to be null.

I fixed that by adding a new variable called p4. This does the job done by p1, except that it correctly holds the variable number used by getuservariable function. myatoi function gets the entire number value that appears first, and so as in your example, the variable $INSTDIR would be used (10+11 = 21 = INST_INSTDIR -> see defines in NSIS\Contrib\ExDLL\exdll.h).

EDIT: I still need to check the existance of the variable though. I don't know how NSIS works totally, but it appears that $INSTDIR is not initialized when nothing is assigned to it.

Thanks for the bug report.

2 bugs in notify system

1) A click on a DirRequester-Button generates two notifies after the selection of a folder with the BrowseDialog: the first event notifies me of a change in the associated textcomponent (that's ok), and the second one notifies me of a click on the NextButton, which I did not touch - this is not ok. Cancelling the BrowseDialog generates only one notify (for the browsebutton).

2) ONTEXTUPDATE does not generate a notify for a textcomponent. I have used ONTEXTCHANGE instead, which works for me, because STATE reflects the input after the keystroke - in contradiction to the documentation - so that it behaves like ONTEXTUPDATE should do.

See the attached Testpage...

By the way: I had some unreproducable exceptions, when going back to the custom page and opening the BrowseDialog for the 2nd or 3rd time.

1) This is not a bug. If you go to the next page, then the page has to be saved and it calls the callback function normally, like IO's default. I'll treat this as a feature request.

EDIT: I mean, a feature request for the implementation of notification flags for pages.

2) Fixed. The docs I still need to fix.

EDIT: Fixed. Note: The control always updates the text before sending the notification. The plugin doesn't handle aborting the new text operation at the moment when setting ONTEXTUPDATE.

3) I'm trying to verify if there are more buffer problems with the plug-in accumulated from older versions. Just see previous comments from other people here. With the addition of BufferSize for Settings section, this can be verified easily.

1) Hmmm... interesting problem. I verified your example again and I concluded that IOEx supports only 1 notification flag activation at a time. Another bug report for mee. There are just so many... 🙁

Curiosity: I just saw the size of InstallOptions.cpp of the IOEx source, and I'm impressed of how much code has been added since lastest IO version:

IO's: 48.6 KB.
IOEx's: 220 KB.

😱! 171.4 KB of difference! It's about 5x bigger than IO's! 😁. Hmmm... I wonder where I spent all that time to get that mountain of code... 😕

Thank you for looking once more after it, because I did not understand answer. Regarding bug #1: the problem is, that I did not click the nextbutton! I have only selected a directory with the BrowseDialog but I want to stay on the current custompage, because in my project there will be more components on the same page. The solution would be an onclick-notify for "Field 2" (instead for field 0) regardless whether I've clicked 'OK' or 'Cancel' in the BrowseDialog. A notify for "Field 0" should only happen when I've clicked on the nextbutton...

For an example, I have modified ioex.nsi to enable the nextbutton only when all textcomponents have an even number of characters. Maybe you can see my problem now...

1) That's the "1 notification flag activation at a time" bug. As I said, I'll fix that later. No need for extra explainations.

A bug report:

In InstallOptionsEx 2.4.2.b4, TxtAlign doesn't work if you don't set TxtColor to some value.
For example:

[Field 1]
Type=Label
Text=Hello
Left=0
Right=130
Top=80
Bottom=88
TxtAlign=RIGHT
TxtColor=0x0

This works and the text is right aligned, but without the line TxtColor=0x0 the text is left aligned.

Regards

I'll verify when I get time to do it. I'm back to school, so it's harder to use the computers at home, principally because most of the time to develop IOEx is at the morning, and school takes part of that + a part of the afternoon, and the other person uses the computer for the rest of the day and night (until 4 o'clock in the morning). I'm sure he has a lot to do by the amount of time I give.

I guess the problem happens because the plug-in doesn't set the flags on the control directly. It just aligns the text when it's customly drawn, making it not to work on non-custom drawn labels. It's seems easy to fix with a code change for me.

I have fixed this in the next version. Thank you for the bug report.

@deguix: asked this before, but i guess it was looked over after those many replies by fromcat. can you estimate when the "\|" escape character will be implemented? just so i can plan ahead.