Strange variable behaviour

[nenad cikic]

I have added a simple procedure that checks if a record exist and returns the record id or returns empty string if it does not exist.

CheckVal             PROCEDURE  (valIn)                    ! Declare Procedure
FilesOpened     BYTE(0)
valOut like(val:sifra)
  CODE
? DEBUGHOOK(valuta:Record)
  do OpenFiles

!point A

  clear(valuta)
  val:sifra=valIn
  get(valuta,val:KeyVAL)
  if not errorcode()
     valOut=val:sifra
  else
     !point C
  end

!point B

  do CloseFiles

  return valOut

val:sifra is STRING(3)

From one update form i call this procedure with a variable as
varx=CheckVal(varx)
in this way i am sure the var on the form is correct.
Anyway when i first enter an non existing value in varx, for example
'111'
i got in return the emty string; and that's OK.
But when i hit the OK on the update form, the CheckVal is again called with varX empty string and in return i get  '111' !?!?
I have put messages in point A/B/C and i am sure that:
- the first time the valIn is '111' and the second is ''
-every time point C is passes
-the second time valOut in point B is '111'

I have solved the problem with
  if not errorcode()
     valOut=val:sifra
  else
     clear(valOut) !ADDED
  end

but i am puzzled what happened.
Can your repeat this behaviour?
Thanks
Nenad

P.S. I hope i am not boring you with my postings. I like very much c2j, it was a tremendous work from your side, and i want to help you make c2j even better (for what i can help anyway).

[Andrew Barnham]

Hi

I think the problem is a defect in c2j compiler's handling of LIKE command.  What happens is that the compiler, if it can, implements LIKE by simply cloning the variable being liked.  But this means that by cloning we also clone the variable's actual value. So when a procedure is called, the variable is preset to the value of the object being LIKEd at time procedure is called. Result is output of the procedure will vary. 

The fix is potentially simple, try this if you have time.  In compiler, find a class called VariableParser.

Line 298 you see this:
                    return new LikeVariable(label, (VariableExpr) exp,false,Static,thread,over);

Change the false to true:
                    return new LikeVariable(label, (VariableExpr) exp,true,Static,thread,over);

This will force LIKE to construct a variable like the base variable, instead of simply cloning the variable at runtime.

Let me know how you get on, if it works, will commit to svn because I think current behaviour is incorrect.

[nenad cikic]

Yes it is working
Thanks
Nenad

[Andrew Barnham]

Ok.  I checked in a fix.

I noticed a new problem; related to fixes I did recently to support your character set; which may help explain some of problems you are experiencing with message boxes.

We recently modified runtime so that strings like <ff> are decoded based on character set.  But if you look at equates.clw you will see this:
ICON:Application  EQUATE ('<0FFH,01H,01H,7FH>')

It is a binary stream, but c2j now wants to treat it as a character stream, based on default character encoding.  Problem is that it will compile to something like this:
public static final String APPLICATION="�\u0001\u0001^?";

Which will not match what is hard coded in runtime: so message icon will not be found and will not appear.
public static final String NONE="\u00ff\u0001\u0000\u0000";

I will quickly add a hack to work around this. If string appears to be a cursor or icon definition then do not run it through charset decoder.

[Andrew Barnham]

Did checkin on svn to cope with icon and cursor equates as mentioned above

[nenad cikic]

I have tried the ConfirmCancel standard message, and yes now i have the icon Question.
Thanks
Nenad