Use of rec.GET in a form gives "Do you want to rename the.."

roynes

I have added a textbox on the orderform, textbox has soursexpr=variable. (not bound to rec.field)
After entring an ordernumber in the textbox, i use rec.Get, this gets the current order to show up, but when leaving the orderform i get the message "Do you want to rename the record"

I have tried to put the code in almost every trigger on the form, i have tried te creat new forms without subforms, but i always have this problem ](*,)

What i actualy want, is a a way to open the correct order with a barcode-scanner.

/roynes

garak

For the Scan of Barcodes and open the Rec for the Barcode (Item, posted document, Order document, and so on) i've created for an customer a form like this:
So he can scan every Barcode and it will open the correct record on the defined form.

Did you have set somewhere some filters before like n OnOpenForm and did you update the form?

kine

Try to do CurrForm.UPATE(False) after you made the Rec.GET.

roynes

Yes, i think this was the trick.
THANK YOU.

But i have problem understanding, becouse im not changing anything in the record.
Can anyone axplain:-)
/roynes

kine

If you change Rec record to another one, and the form will not be updated, the xRec is old record (before get) and Rec is new one, but the form things that it is same record, but with new values, thus suggesting the rename... May be there is another way around - to mak the get on xRec too... but for me the Update is much cleaner way...

jversusj

)hello,
I have a related problem. i posted about it before a few months back but didn't get anywhere with it. this thread rekindled my interest in solving the issue.

we have a customization that launches a form containing special notes when you bring up a customer card (don't ask... :oops:). anyhow, when the user is working with non-maximized forms, this works as intended. the user searches for a customer no. & they encounter 1st pop-up, closes it, encounters 2nd pop-up (closes it), REPEAT until no more special note types (pop-ups) are found. when they close the last special note pop-up form, they find themselves sitting on the customer card.

now, when the user has forms maximized and follows the above procedure, they encounter the "Do you want to Rename the..." message upon closing the first pop-up. I have found that this is because the focus is dropping back to the customer card they initiated the search from (drops back into OnFindRecord trigger of customer card and xrec doesn't equal rec so... :roll: ). however, with forms non-maximized, the focus does not fall back to the customer card - instead, the C/AL note logic continues the REPEAT.

I thought maybe if i added an action, i could force the focus back to the logic written in the trigger that launches the form.

  IF NoteType.FIND('-') THEN
    REPEAT
      Note.RESET;
      Note.SETRANGE("Customer No.",Customer);
      Note.SETRANGE("Note Type",NoteType."Note Type");
      IF Note.FIND('-') THEN BEGIN
        IF FORM.RUNMODAL(50000,Note) = ACTION::Close THEN
           bClosed := TRUE;
      END;
    UNTIL NoteType.NEXT = 0;

unfortunately, however, the action logic is never carried out - regardless of if my forms are maximized or not. Any ideas? the above code sits in a function on the table that contains the notes.

i basically need a way to make sure the C/AL is called as written instead of dropping out of the above REPEAT back into the OnFindRecord trigger of the Customer Card (which leads to my rename issue).

canadian_bacon

Have you tried to call this from OnAfterGetCurrRecord instead?

jversusj

canadian_bacon wrote:

Have you tried to call this from OnAfterGetCurrRecord instead?

i came up with the same thought last night! i will try it today and post back on it if it works any better that way.

jversusj

i moved the logic that calls 'pop-ups' to OnAfterGetCurrRecord trigger on customer card. the rename problem persists after closing first pop-up. nice thought, but no dice.

gerdhuebner

jversusj wrote:

i moved the logic that calls 'pop-ups' to OnAfterGetCurrRecord trigger on customer card. the rename problem persists after closing first pop-up. nice thought, but no dice.

Well, may be it is a problem of the NAV version. I tried the following code in the OnAfterGetCurrRecord trigger of the form "Customer Card" in a standard database of NAV 2009 Classic SQL:

CommentLine.SETRANGE("Table Name",CommentLine."Table Name"::Customer);
CommentLine.SETRANGE("No.","No.");
IF CommentLine.FIND('-') THEN
  FOR i := 1 TO 2 DO      // to simulate multiple popups..
    FORM.RUNMODAL(FORM::"Comment Sheet",CommentLine);

I 've got no problems with annoying rename-questions not even in full screen mode...

I don't understand how your code worked in any way in the OnFindRecord trigger of the "Customer Card"... - is it really the whole code in that trigger?

jversusj

gerdhuebner wrote:

jversusj wrote:

i moved the logic that calls 'pop-ups' to OnAfterGetCurrRecord trigger on customer card. the rename problem persists after closing first pop-up. nice thought, but no dice.

Well, may be it is a problem of the NAV version. I tried the following code in the OnAfterGetCurrRecord trigger of the form "Customer Card" in a standard database of NAV 2009 Classic SQL:

CommentLine.SETRANGE("Table Name",CommentLine."Table Name"::Customer);
CommentLine.SETRANGE("No.","No.");
IF CommentLine.FIND('-') THEN
  FOR i := 1 TO 2 DO      // to simulate multiple popups..
    FORM.RUNMODAL(FORM::"Comment Sheet",CommentLine);

I 've got no problems with annoying rename-questions not even in full screen mode...

I don't understand how your code worked in any way in the OnFindRecord trigger of the "Customer Card"... - is it really the whole code in that trigger?

hi there, we do have 3.7b objects...

i think there is a misunderstanding, the code that calls the pop-up forms lies in the OnAfterGetCurrRecord trigger, but when the screen is maximized and you close the first pop-up, the code jumps back to the customer card OnFindRecord trigger (instead of continuing in the REPEAT statement that is launching the pop-ups).

thanks for the follow-up and testing on your end.

Savatage

jversusj wrote:

when the user is working with non-maximized forms, this works as intended.

Not knowing the form or the whole setup I was wondering
What happens when you set Maximizable to "No" to that form?
or looking into the RunFormOnRec property?

you can size it to fill the screen but it's not considered "maximized"

gerdhuebner

jversusj wrote:

...we do have 3.7b objects...

Well, you could try to check if it is indeed a version problem, if you put my code from above into a (clean) Customer card and make some tests in full screen and not-full-screen mode, respectively...

jversusj

Savatage wrote:

jversusj wrote:

when the user is working with non-maximized forms, this works as intended.

Not knowing the form or the whole setup I was wondering
What happens when you set Maximizable to "No" to that form?
or looking into the RunFormOnRec property?

you can size it to fill the screen but it's not considered "maximized"

i played with this option and found that the users didn't like it - can't remember why. I guess i can revisit that...

thanks again to all.

jversusj

gerdhuebner wrote:

jversusj wrote:

...we do have 3.7b objects...

Well, you could try to check if it is indeed a version problem, if you put my code from above into a (clean) Customer card and make some tests in full screen and not-full-screen mode, respectively...

hello - i tried your code in a local install of 4.0 sp1 and it worked. it could be a version thing, BUT i will take another peak at this logic in my 3.7b system. thanks!

EDIT:
okay - i rewrote what it was supposed to be doing like your example and tested with a maximized form. if i scroll between records or use the previous/next buttons in the toolbar, it works! unfortunately, if i use the find tool (Ctrl+F), it still asks about a rename. this is not the case in the 4.0 system.

this is interesting because my 4.0 system is using the 4.0 client, but my 3.7b system is using a 5.0 client. i would think this behavior is tied more to the client than the codebase, but what do i know?



EDIT 2:
i looked again at our current live code and tried it out. the scroll action works with our existing code as well - it is always the find that causes that rename issue. sorry for the misspeak - it's been a while and i forgot the forest for the trees. either way, the pop-ups do not ask for rename in 4.0, although they do exhibit some unusual activity when closing a find dialog (pop-ups ran 4 times instead of 2 that the loop asked for).

canadian_bacon

have you tried to set UpdateOnActivate to "No"?

jversusj

canadian_bacon wrote:

have you tried to set UpdateOnActivate to "No"?

oh man oh man! \:D/

no. i had not tried this because i did not really know about it. i looked up what this does in the application designers guide, and it states: "specify whether you want the system to update the form when it is activated."

i don't really understand what this means however. I made the change and tested navigating through records and that all seemed fine and unchanged from what i had seen before. then i updated a field that has code in the onvalidate and it updated the other fields as necessary right on the form - so it did update the form.

of course, thanks to mibuso, i found what it really does: viewtopic.php?f=23&t=20862&hilit=updateonactivate

thanks everyone, i believe "my" problem is solved pending some internal procedure discussions!

=D>

EDIT
:oops: i think i spoke too soon. when i test this further, i see that maybe it isn't my solution. I opened a second client in my test Db. in 1 client i updated an address on a customer card. in the second client, i searched for that customer and did not see the changed address. i thought it would update if i just moved off the record and came back, but alas - it did not.

oh well!

EDIT 2:
can anyone explain this property in more detail? in my above test, i change the address. in my second client, the form does not update (because i told it not to - i understand), BUT if I ZOOM on that record, the table does not reflect the change either. When i go to object designer and view the record directly, i see the changed value. if i go back to the form, i still do not see it (even if i zoom again). I can only see the change if i close the form and start over. does this mean the entire contents of the customer table are being cached when the UpdateOnActivate property is no? that's how it appears to me.

gerdhuebner

jversusj wrote:

... it is always the find that causes that rename issue...

I found some trouble with the Ctrl+F in NAV 2009, too.
1st, the popus appear twice (as you mentioned already) - this can be remedied by the following extension:

IF "No." <> xRec."No." THEN BEGIN
  CommentLine.SETRANGE("Table Name",CommentLine."Table Name"::Customer);
  CommentLine.SETRANGE("No.","No.");
  IF CommentLine.FIND('-') THEN
    FOR i := 1 TO 2 DO     // to simulate multiple popups
      FORM.RUNMODAL(FORM::"Comment Sheet",CommentLine);
END;

After all I found a method to crash down the client, even in non-full-screen mode, when the "Find as you type" option was active:
- Type Ctrl+F (the Find Window pops up)
- Type some expression, that will find a customer with popups -> the first popup pops up
- The focus is now in the popup window
- Click onto the Close Button in the find window (the find window will not close anyway...)
- Type ESC several times
- the client crashes.