Author Topic: Clearing up some CustomMem misunderstandings.  (Read 3507 times)

vonsmith

  • Hero Member
  • *****
  • Posts: 602
    • View Profile
Clearing up some CustomMem misunderstandings.
« on: October 01, 2003, 12:42:30 pm »
There are some potential problems using the CustomMem EncodeVar() and DecodeVar() functions as discussed on this forum. I know some people have had difficulty in getting these functions to work as desired. I implemented the Medeksza code I downloaded from this forum last night. It works, but not quite as expected.

As some of you know VBscript variables are actually variants. Type definitions, (boolean, single, string, etc.) are overly flexible in VBscript as compared to more structured languages such as C++. Variable types in C++ can't change unless the programmer uses the "cast" function to deliberately change it. VBscript should be so robust.

How I Set Up My Test:

I copied and pasted the CustomMem functions into the hal5.uhp file. The EncodeVar() and DecodeVar() functions were pasted into the file towards the end just prior to the "Sub AboutOptions()" definition where the other functions are declared. The DecodeVar() usage is just after the start of the GetResponse() function to retrieve the variables and the EncodeVar() usage is towards the end just prior to the line:

"GetResponse = GetResponse & HalBrain.StoreVars(WorkingDir, Hate, Swear, Insults, Compliment, PrevSent, LastResponseTime, PrevUserSent, CustomMem, GainControl, TopicFocus)"

That is when the encoded CustomMem variables are stored away.

Some Examples of What I Found:

The EncodeVar() function stores variables by concatenating them into a single string variable. The DecodeVar() function extracts them out again by doing a text search and extracting the original variable data. The problem is that any variable that is encoded, whether it be a type integer, boolean, etc. always gets changed into a type string when it is encoded.

An Example of What Undesirable Effects Can Happen:

uservar = True  <--- uservar begins life as a boolean, True or False.

var1 = TypeName(uservar)  <--- This function returns the word "boolean" and stores it in var1 indictating that uservar is indeed a type boolean.

If uservar = True Then [do something]  <--- uservar will test boolean "True" here and do something.

CustomMem = EncodeVar(uservar, "uservar")  <--- Encode uservar into CustomMem.

uservar = DecodeVar(CustomMem, "uservar")  <--- Decode uservar out of CustomMem.

If uservar = True Then [do something]  <--- uservar will NOT test boolean True here. uservar has become a type string.

If uservar = "True" Then [do something]   <--- This will work since uservar is a type string.

var1 = TypeName(uservar)  <--- This function returns the word "string" and stores it in var1 indictating that uservar is now a type string.

uservar = CBool(uservar)  <--- Normally you would expect CBool to convert uservar back into a boolean, but this causes a type mismatch error instead. However...

If uservar = "True" Then uservar = True  <--- This forces uservar to revert back to a type boolean. Strange huh?

var1 = TypeName(uservar)  <--- This function returns the word "boolean" and stores it in var1 confirming that uservar is now a type boolean again.

If uservar = True Then [do something]   <--- This works now.


The Similar Situation Occurs for Numerical Variables:

uservar = 6  <--- uservar begins life as a type integer.

var1 = TypeName(uservar)  <--- This function returns the word "integer" and stores it in var1 indictating that uservar is indeed a type integer.

If uservar > 5 Then [do something]  <--- uservar will test true here and do something.

CustomMem = EncodeVar(uservar, "uservar")  <--- Encode uservar into CustomMem.

uservar = DecodeVar(CustomMem, "uservar")  <--- Decode uservar out of CustomMem.

If uservar > 5 Then [do something]  <--- uservar will NOT work here. uservar has become a type string, thus a type mismatch will occur.

var1 = TypeName(uservar)  <--- This function returns the word "string" and stores it in var1 indictating that uservar is indeed now a type string.

uservar = CInt(uservar)  <--- I haven't tried this, but it should convert uservar back into a type integer.

If uservar > 5 Then [do something]  <--- This should work now.


Recommendations:

For boolean flags in my programs I'll use type string expressions instead of type boolean. Example: Instead of uservar = True I'll use uservar = "ON" or uservar = "OFF" and test as: If uservar = "ON" Then [do something]. This avoids the problem.

For integer variables I'll have to convert them back using CInt() immediately after each DecodeVar() call. Similarly for other numerical types.

I hope this helps in using CustomMem. I apologize in advance for any typo's or mistakes in the above analysis. I've tried to be careful and accurate.


= vonsmith =
 

Don Ferguson

  • Sr. Member
  • ****
  • Posts: 303
    • View Profile
    • http://www.cortrapar.com
Clearing up some CustomMem misunderstandings.
« Reply #1 on: October 01, 2003, 04:47:08 pm »
Hello,

Your investigation is very logical and your explanation is very lucid, concise, valuable, and understandable.  

Your "workarounds" also sound like the simplest and most robust ways to handle the issues.

Great work!  Thank you!

Sincerely,

Don
Don Ferguson
E-mail: fergusonrkfd@prodigy.net
Website: www.cortrapar.com
Don's other forum posts: http://www.zabaware.com/forum/search.asp?mode=DoIt&MEMBER_ID=274

brianstorm

  • Jr. Member
  • **
  • Posts: 76
    • View Profile
Clearing up some CustomMem misunderstandings.
« Reply #2 on: October 02, 2003, 06:59:06 am »

yeah, I ran into that boolean thing too. What I did was just refer to

it as "True" thereafter. Ah well, I'll learn!

What I did in my postings using the CustomMem was after it was done being

used I cleared it by declaring CustomMem = "". In hindsight that might

not be the best choice as there may be variables that need to be set during

the entire course of a conversation. Hmm

CatAtomic