Form Runmodal - Temptable

JPHSC

The goal is to make a sort of wizard that only alters the record when the Finish butten is hitted.

When i have a temptable and i copy the current record to the temptable

temp.init;
temp.transferfields(rec);
temp.insert;
temp.setrecfilter;

When i try this ;

IF FORM.Runmodal(Form::"My Form", temp) = action::lookupOK THEN BEGIN 
  rec.transferfields(temp);
  rec.modify;
  CurrForm.update(FALSE);
END;

everything is working perfectly.

When i do it with a variable

MyForm.SETRECORD(temp);
MyForm.Lookupmode(true);
IF MyForm.Runmodal = Action::LookupOK THEN BEGIn
  MyForm.GETRECORD(temp);
  Rec.Transferfields(temp);
  rec.Modify(FALSE);
  CurrForm.update(FALSE);
END;

I get an error... I don't get it ..

Belias

you got an error...ok.....................
What is the error?!?! :shock:
maybe "...does not exists?"
try to use

rec.insert;

instead of

rec.Modify(FALSE);

...just an idea looking at your piece of code...you should provide the error text :-k

JPHSC

i don't get an error, it's just that the second way doesn't seem to use the temptable for the form, so that the record is always updated.
I don't want the 'actual record' to be updated, but only the temptable. And if the user chooses finish the code update the actual record, if the user chooses cancel, all the changes are made to the temptable, not the actual table. All i want to do then is clear the temptable so no changes are saved.

Belias

MyForm.SETRECORD(temp);
Currform.update(false);

you don't need this instruction:
maybe your problem is generated from the use of both setrecord and setrecfilter...(never tested)
setrecfilter should be the only thing you need, try it

David_Singleton

JPHSC wrote:

The goal is to make a sort of wizard that only alters the record when the Finish butten is hitted. ...

Just don't do this. You owe it to you client to be honest to them and say NO. Teach them Navision and tell them that if they don't like Navision, then maybe its best they go back to their old product.

I have seen many attempts to mimic the wizard concept in Navision, (Items, customers, vendors, sometimes even sales orders), it just get more and more complex and more and more expensive.

Best is to stop now.

idiot

Boss,

Teach them Navision and tell them that if they don't like Navision, then maybe its best they go back to their old product.

M$ won't be treating you any beer any time soon...

Not sure if I agree with you on this...
One of the flaws of Nav is the immediate unintentional update of records in Master Cards which uncountable complaints were received & requests to do something about it.
One of the common requests is to disable edit unless authorized in some way or intended.
Definitely such kind of wizards is going to be expensive initially, but it becomes an advantage for you to have such wizard when other competitors cannot or unwilling to provide. It doesn't modify Nav business logic & adds value (read $) to what the implementer can provide.

DenSter

idiot wrote:

One of the flaws of Nav is the immediate unintentional update of records in Master Cards which uncountable complaints were received & requests to do something about it.

I rather consider it as a strength of the application, I like the way it works, and now that I am used to it I think apps that force you through a wizard are cumbersome. In my almost 10 years of experience with users asking about a save button, discussions about this particular topic usually don't take more than 10-15 minutes, and by that time users completely accept it the way that it works, and more often than not they end up really liking the way it works.

idiot wrote:

One of the common requests is to disable edit unless authorized in some way or intended.

Standard NAV already provides this functionality. Not all users have to have edit rights to master tables, you can manage this by setting permissions. People who do not use care when using the Card forms should not have access to this data to begin with. If there's a need to look at data by users with edit rights, you can make the card form not editable with a simple click of the button and a single C/AL statement. Creating a wizard for modification is completely against the look and feel of the entire application, and once you start doing that for one table, users expect it for all tables. Customers might pay for one or two of them, but then the expectation is that it simply works that way, and now you have made upgrading even more expensive.

Sounds like a pretty good way to generate some business... :-k

JPHSC

I agree, but i'm JUST the developer ... ](*,)
It has something to do with the hosting licence for the small ( dumb & not interested ) customers .. ?

David_Singleton

JPHSC wrote:

I agree, but i'm JUST the developer ... ](*,)
It has something to do with the hosting licence for the small ( dumb & not interested ) customers .. ?

Sorry but that is just BS, this all goes back to lazy sales people that just say "Sure Navision can do anything".