Scope of variables

FommoFommo Member Posts: 138
Hi!

I'm used to read code and I'm pretty comfortable with C/C++/Java and such, but now I'm stuck in Navision.
I have extracted the lines below from a C/AL code:
IF GET(Type::Document,Languagecode,SearchField) THEN
    EXIT('');
  IF NOT DocText.GET(Type::Document,Languagecode,SearchField) THEN BEGIN
    ...
  END;
The function belongs to a table Translation Texts and it should look for a translation for the text that is specified with the parameter SearchField. Furthermore there is a global variable Languagecode (Text) and a Record variable DocText that points to the table Translation Texts (the same table as the function belongs to).
As my trained eye would like to see the lines above I would say that one of them should be executed (one of the IF:s should be TRUE). The funny thing is that none of them does. And I have debugged and debugged, but I can't see why. :?

When I run a watch on the variables I find that Languagecode is never set. I guess that is why the first IF-sentence is FALSE. The funny thing is that somehow DocText gets the value of the right line. So somehow the second GET finds the translation in the correct language. :?

So, my final suggestion is that it is about the scope. DocText record do have a Languagecode variable inside. Is it that Languagecode that is used in the second IF? In that case it would explain why it works.

If not... Can someone explain how the lines above is executed, please? :?:

Comments

  • FommoFommo Member Posts: 138
    Since no one found any answer yet I have tried to figure it out.
    I found that when using Get without bounding it to any record it will use the first parameter as the search table.

    In my case that would cause the first GET to look into table "Type::Document". And since I doubt that such a table name even would be able to create the GET will always return FALSE and the IF is not executing the EXIT statement.

    In the next IF statement the GET have a table bounding and the search will be correct and return TRUE if the translation text was found in the table. In this case it will result that the statements inside will NOT be executed since the boolean is negated.

    So I guess that is the answer. The code is just so bad it should be put into a trashcan... And the worst thing is that this code belongs to an addon from a Microsoft Business Solution Partner.

    Well, even the greatest can fail!
  • BGIBGI Member Posts: 176
    I Think the first get goes to the table defined in the rec variable, the second one to a table defined in your globals. Can this be the difference?
    Rgds
    Benny Giebens
  • FommoFommo Member Posts: 138
    BGI wrote:
    I Think the first get goes to the table defined in the rec variable, the second one to a table defined in your globals. Can this be the difference?

    Yeah, I thought so too first. It looked logic at first sight. But then I realized that the rec table and the DocText variable points to exactly the same table. So if the item is found in DocText it should have been found in the first GET too.
  • kinekine Member Posts: 12,562
    Fommo wrote:
    Yeah, I thought so too first. It looked logic at first sight. But then I realized that the rec table and the DocText variable points to exactly the same table. So if the item is found in DocText it should have been found in the first GET too.

    Check the Property "Temporary" on the global variable DocText...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • DenSterDenSter Member Posts: 8,307
    look for a statement like this somewhere above your GET:
    WITH SomeRecordVariable DO BEGIN
    
    The GET statement is then applied to the SomeRecordVariable. It might also be that your record is still in memory because it is set as a global.

    If your first IF statement returns FALSE then it will exit and it will not even get to the next one.
  • FommoFommo Member Posts: 138
    kine wrote:
    Check the Property "Temporary" on the global variable DocText...

    I've checked that now. It's not a temporary record.
Sign In or Register to comment.