This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Behavior of CtrlGetText
Started by
kirann_hegde
, Sep 07 2009 13:58
8 replies to this topic
Posted 07 September 2009 - 13:58
I have a dialog with 3 edit boxes:
First edit box - collect the user name
Second and third edit boxes - collect the passwords
When the user clicks on the next button, the data in all of these text boxes is collected into installscript variables using CtrlGetText.
The data collected from the the first edit box is eventually passed as an input argument to a C# library. Upon debugging the C# library this data is getting passed from Installscript to C# with the appending of a large number of \0 characters. Upon debugging the installscript project, this is not evident in the installscript debugger.
However when the C# library is debugged, this becomes evident in the Visual studio debugger.
So for example: if the data entered in the first text box is abc, this is getting appeneded with lots of \0 characters before being passed to the C# function.
The strange thing is that the data in the second and third text boxes is passed intact. When i trim the data got from the first text boxes for trailing spaces, this problem ceases to exist.
Question:
1)Is there any attribute i need to set on the text boxes which would prevent this from happening or is this something random and is exhibited by installscript?
2)Is this something random?
3)After collecting the data from the text boxes, i am using StrLengthChars function on the data. Is this function appending the \0 characters?
Regards,
Kiran Hegde
First edit box - collect the user name
Second and third edit boxes - collect the passwords
When the user clicks on the next button, the data in all of these text boxes is collected into installscript variables using CtrlGetText.
The data collected from the the first edit box is eventually passed as an input argument to a C# library. Upon debugging the C# library this data is getting passed from Installscript to C# with the appending of a large number of \0 characters. Upon debugging the installscript project, this is not evident in the installscript debugger.
However when the C# library is debugged, this becomes evident in the Visual studio debugger.
So for example: if the data entered in the first text box is abc, this is getting appeneded with lots of \0 characters before being passed to the C# function.
The strange thing is that the data in the second and third text boxes is passed intact. When i trim the data got from the first text boxes for trailing spaces, this problem ceases to exist.
Question:
1)Is there any attribute i need to set on the text boxes which would prevent this from happening or is this something random and is exhibited by installscript?
2)Is this something random?
3)After collecting the data from the text boxes, i am using StrLengthChars function on the data. Is this function appending the \0 characters?
Regards,
Kiran Hegde
Posted 07 September 2009 - 16:38
InstallScripts String daTA TYPE IS SIMILAR TO THAT IN C, i.e. each string is terminated with a NULL character \0. Anything after this terminator is garbage that might exist in the buffer after the end of the string. If it's all \0s then I guees the buffer was nulled before the sring was copied in.
Stefan Krüger
InstallSite.org twitter facebook
Posted 08 September 2009 - 06:28
ok thanks.Makes sense.
If this is the case, then why is it that the data in the other text boxes do not have this problem?
If this is the case, then why is it that the data in the other text boxes do not have this problem?
Posted 08 September 2009 - 13:30
I don't know wha they appear to be different, but I believe it must be something in your code. Since \0 marks the end of the string, there can't be (by definition) " a large number of \0 characters" at the end of the string. There is only one \0 at the end of the string, and then some \0 characters after the end of the string, which doesn't matter.
Maybe the length of the password string buffer matches exactly the number of characters that a user is allowed to enter, while the user name box isn't full? What happens if you enter fewer characters in the password fields?
Maybe the length of the password string buffer matches exactly the number of characters that a user is allowed to enter, while the user name box isn't full? What happens if you enter fewer characters in the password fields?
Stefan Krüger
InstallSite.org twitter facebook
Posted 09 September 2009 - 12:54
No luck. I used fewer characters for the password field and still its just the user name field which has the issue.
BTW, there is one thing. This project file(.ism ) was earlier in IS 11.5 professional format. We upgraded the project to IS 2009 format. After this upgrade, this was the only text box which was added. So does Install Shield exhibit strange behaviours in such cases?
BTW, there is one thing. This project file(.ism ) was earlier in IS 11.5 professional format. We upgraded the project to IS 2009 format. After this upgrade, this was the only text box which was added. So does Install Shield exhibit strange behaviours in such cases?
Posted 09 September 2009 - 22:41
Unicode support maybe?
Stefan Krüger
InstallSite.org twitter facebook
Posted 11 September 2009 - 11:40
Can you elaborate on Unicode support? What exactly do you mean here?
Is there any setting within InstallShield 2009 IDE which allows me to specify if the strings in the text boxes get passed as Unicode or ANSI?
Is there any setting within InstallShield 2009 IDE which allows me to specify if the strings in the text boxes get passed as Unicode or ANSI?
Posted 12 September 2009 - 01:39
I was thinking about what changed between these two InstallSield versions, and I seem to remember that Unicode support was added or improved. Maybe this caused a change in the control setting bits.
Stefan Krüger
InstallSite.org twitter facebook
Posted 23 September 2009 - 15:31
In the transition from IS 12 to 2009, I've noticed the text of a password entry is shifted slightly to the right -- the text no longer lines up with non-password text box.
Perhaps the unicode shift causes this interface change as well.
Unless I've done something wrong, I would consider this a bug in the software.
Perhaps the unicode shift causes this interface change as well.
Unless I've done something wrong, I would consider this a bug in the software.