bugs/features

[Will]

I have noticed a few bugs in this program so far while evaluating it and also I have have some suggestions for features.

Bugs:
-When returning a value into an undefined variable on a DLL call, it said 'ALLUSERS' was undefined, when in actuality it was 'RESULT' that was undefined. I'm guessing this is an 'off-by-one' kind of mistake in a list somewhere in your code.

-When trying to Cut 8 controls that were in a group box, I got a serious error the instant i hit Ctrl+X after selecting the controls.

-When running the installer, the back color of the dialogs is not drawn, and instead, whatever was behind the dialog box is drawn inside the window, as if the window were transparent. This does not occur when running the installer i made in debug mode. (this may or may not be my fault, but I have no idea what could cause this since the back color of a window should always be drawn)

-When closing an unsaved project there should be a Cancel option. This would have been very useful when I accidently opened two instances of the same project and didn't remember which one I had modified, but had already clicked on the close button.

Features
-UNDO!!! I know from personal experience that this can be very difficult, but an undo feature (at the very least in the script editor) would be extremely valuable. I cannot overstate how important an UNDO feature is.

-Search & Replace in the script editor. This is also an incredibly valuable tool.

-When closing the Dialog editor, it should ask to save if there have been any changes (at the very least you can make it always ask to save since chances are that if you opened up a dialog to edit it, you did make changes to it).

-When editing values in the properties window in the Dialog editor, they should automatically be applied. It's easy to forget to hit enter and then lose the changes when selecting a different object.

-Arrays in the script. The ability to have arrays in the script and loop through them would save a heck of a lot of time. Right now it's possible with the string parser and GOTO statements, but that's a lot of code for just a simple loop.

-The ability to check for running processes/services. I can imagine that a lot of installations would need to have certain services or processes stopped so that they can be installed. This is certainly true for more complicated programs.



Overall I'm very impressed with Installaware, for it's price it is quite a value. With a little bit clever programming and creating custom DLLs I can get it to do just what I need it to do. Though there are a few bugs, I've seen far worse software, and they are not very major bugs anyway. Also I'm impressed with the support on these forums. Thank you for your quick responses!

[Will]

Also:

Bug - The "Define Interactive Characterstics" window changes the case of words true and false to be "True" and "False", and will not let me check if Caption is set to "TRUE". I had to edit the .miaf file outside of InstallAware.

Feature - The DLL call function should be allowed to return a string.

[Will]

And also:

I'm having trouble passing a string by reference on a call to a DLL. It may be that I don't know how to work with char* very well, but I cannot figure this out. Thanks.

[sinan]

Thanks for your bug reports and suggestions. I have passed them on to the development team and you will be pleased to know that some are already scheduled to be addressed in the Service Pack 1 update for InstallAware 2005.

I do have some feedback on some of the items below:

1) Returning a string from a DLL function is ill-advised. Who allocates and frees up the memory for that string? You will notice that in the entire Windows API, there isn't a single function that returns a string as its result. Therefore, in accordance with this programming best practice, the Call DLL Function plug-in will not let you handle string returns. If you do have a function with string returns, try passing them in a parameter instead. This way the caller can allocate and then free the memory.

2) The background color of dialogs should be drawn in most cases. Using XP themes can sometimes change this color to the background color of the parent control, but in no cases will the background of the dialog actually be "transparent". Could you send me the dialog in question, and possibly a screenshot of the "transparent" appearance, so I could take a look at this?

Thanks once again for your bug reports and feature suggestions!

[Will]

If you do have a function with string returns, try passing them in a parameter instead. This way the caller can allocate and then free the memory.

This is what me and my coworker have been trying to do for hours. So far we've found out how to change the string passed in using memcpy, but we cannot figure out how to allocate more space for the string.

So we would like to know the exact function header used to pass a string by reference and the exact code to replicate the string.

Thanks,
Will

[sinan]

That actually depends on your programming language. I am sure a Google search would yield fruitful results - be sure to check in Google Groups as well.

[Guest]

I'm coding in C++. I feel like this should work, but the variable in the Installaware script is not changed by this. Passing the int by reference works just fine.

Code: Select all

__declspec(dllexport) void __stdcall RefTest(long& intRef, char* charRef)
{
   intRef = 100;
   charRef = new char[80];
   charRef = "fjasdkjfljelifjlaiejflaijelfiajelfjiaef\\0";
}

If i try to pass the pointer by reference like this:

Code: Select all

__declspec(dllexport) void __stdcall RefTest(long& intRef, char*& charRef)

Then it just makes the first 4 characters of the string passed in gibberish.[/code]

[Guest]

I'm using a pointer to a string in these DLL calls. Would it just be easier to use an allocated string buffer? Ideally I'd like to have the ability to allocate more space for the string in the DLL function, but if that is too difficult then I will do it the other way.

[sinan]

You probably just want to use char&? Why not try that and let me know how it goes.

[Will]

Using a char& only lets me modify the first character of the string. This makes sense because I am just passing a reference to a single character. What I need is a reference to a char* so that the changes I make to that pointer are maintained. However, as I explained before, that does not work. I'm beginning to think that reallocating a string in a DLL call is not possible. Have you or your developers gone through and tested this?

[sinan]

Please copy-paste the code below into an empty InstallAware project:

Code: Select all

~InstallAWARE Clipboard Data~
~MessageBox~
~{572290EA-3E8B-4FD3-BDE7-AEBA56045669}~
~Results~
~FXNVAR: $FXNVAR$$NEWLINE$RESVAR: $RESVAR$~
~0~
~1~
~~
~Call DLL Function~
~{2F03B3CF-FA4A-49D5-825D-0C3865A83141}~
~kernel32.dll,GetTempPathA,"double word",RESVAR,"double word",1024,"allocated string buffer (MAX_PATH length)",$FXNVAR$,$~
~mIDEFunc.dll\\mEXEFunc.dll~
~Set Variable~
~{554592BD-21B9-4981-A528-17104D3F133F}~
~RESVAR~
~~
~Set Variable~
~{3678B3C2-5507-4107-8F97-D15E65B60413}~
~FXNVAR~
~~

(Be sure to copy-paste the entire code region above)

This sample calls the GetTempPath Win32 API function, and passes the variable $FXNVAR$ to the function. When the function returns, $FXNVAR$ contains the correct value of the temporary path.

I believe this is what you are looking for?

[Will]

Never mind. I have already gotten it to do what I need it to do. As long as I'm not returning strings longer than 255 characters, it will work.