I stumble over this problem a lot and wonder if there is any solution to it. I often want to re-use existing code in a batch program which originally was intended for online use. Thus the existing code makes heavy use of the CONFIRM command. Because I am not suppose to touch this code, I have no other choice than to copy the code into my own codeunit and reimplement it there. Not exactly maintenance-friendly! If only one could “auto-answer” those CONFIRM messages, all my troubles would go away… is there a way do this?
Just touch the code. [:D] Make a global boolean SkipConfirm in each object you have to skip a CONFIRM in. Set it to True when you run your batch program. You just have to alter the code a little to make the CONFIRM dependent on SkipConfirm. Shouldn’t be a problem.
The code isn’t mine, it comes from another company which could overwrite the code at any time…
I’m not sure who wrote the code or what it does, but it might not hurt to contact them. I had a recent situation where I needed to programmatically alter certain things in the Purchase Header. This would trigger about 123,986,897,892,447 confirmations about “Do you want to do this”, and “do you want to do that” etc. That particular table has a condition on each confirmation that says something like IF NOT HideValidationDialog AND (whatever) THEN (…show whatever annoying question…). I used the PO Header function SetHideValidationDialog(FALSE) to turn off this feature prior to making my changes to the record, then I could freely do what I needed to do, and these confirmations would not appear. If the code in question doesn’t have such a feature, then maybe the author of that code could provide such a facility, and you would be able to do what you need to do, and not have to worry about future updates to that code. KC
quote:
The code isn’t mine, it comes from another company which could overwrite the code at any time…
Originally posted by urs.eichmann - 2005 May 25 : 16:19:53
You can also let something on the Enter button Sorry [:D]
Urs really don’t be scared to change the code. If it is written properly, then it should be easy to change, that is the beauty of Navision. If it is not writeen well, then you have my permission to take to the devleopment team with a base ball bat.