How to retain a user-set key?

Mike_HWG

I have a form where one of my users likes to set the sort order that is not the primary key.
When they press a certain button, a function runs. That function changes the key to something that is more optimized for its use, runs, then returns control to the user.
The user is then unhappy because the form is now sorted by a different key.

How can I capture the key, change it to something else for my function, then change it back?

I tried this which does not work:

PrevKey := MyTable.CURRENTKEY;  // PrevKey is a Text variable
MyTable.SETCURRENTKEY("field 1","field 2","field 3","field 4");
// .
// ..
// ...
// Do stuff
//
MyTable.SETCURRENTKEY(PrevKey);  //Doesn't work!!

At this point I could create a semi-complex function that inserted double quotes around each element in the variable, but I'm wondering if there's a better way to do this?

My current thought is changing the form's default key to something else. Then, I can use GETFILTERS and do a FORM.RESET, then a SETFILTER... but it seems like there's a better way??

David_Singleton

YOu are going about this completely the wrong way.

Just leave the form as it is. The change should be to call you function with a new instance variable of the same record. Have a look how the printdocument function works, it should be exactly what you are looking for.

Mike_HWG

Are you talking about the PrintReport function, such as in CodeUnit 92?

I should mention that the function I'm running modifies the table that is presented in the form, among some other things.

David_Singleton

Printing an invoice updates the "No. Printed" field in the invoice header after printing.

Mike_HWG

OK, I see what you are talking about now.

In my situation, the previous coder created a codeunit function that passed the records in as a VAR, set the key, did a FINDSET and some processing, and then did a MODIFYALL after the loop.
I'm going to see if I can get rid of the VAR property and try using a form.UPDATE to get around that.

David_Singleton

Mike_HWG wrote:

OK, I see what you are talking about now.

In my situation, the previous coder created a codeunit function that passed the records in as a VAR, set the key, did a FINDSET and some processing, and then did a MODIFYALL after the loop.
I'm going to see if I can get rid of the VAR property and try using a form.UPDATE to get around that.

Often its best (and even less work) to fix up someone else's mistakes and get things working properly than to keep struggling with stuff that doesn't work properly.