dataport RUNMODAL - suppress request form

jversusj

Hello,
i searched the forum for some tips on this, but was unable to find a solution.

I have a codeunit that is calling a Dataport using RUNMODAL. it looks something like this:

DP50088.DefineFileForImport(sFilePath);  //send programmatically defined filepath to dataport to import
DP50088.RUNMODAL;
CLEAR(DP50088);

where DP50088 is a dataport variable.

In my Dataport, i set the UseRequestform property to No and this works fine. CU can be run and the user sees nothing.

now the issue; this is part of an integration and we need to do some step testing (so i need to run the DP directly) when things break and it is inconvenient to change the UseRequest property in the object and recompile. we have to worry about who else is in the DEV system and what they may be doing. i thought, it would be nice to add a parameter to my call and tell the CU not to launch the request form. i could then manually run the DP whenever i need to test a particular file issue. i cannot find the right command, however.

unlike with a report variable, i do not have DP50086.USEREQUESTFORM available to me. Is there a trick i am missing here?

thanks in advance!

Belias

If you have not personalized the requestform, you can use FILENAME and IMPORT function in order to set the name and the direction of the dataport dynamically...in this way, if you do and ALT+R from obj designer, you can choose parameters, if you run it from the process, you won't see anything...you can also get rid of the function you created in your dataport.
I point out that this solution only applies if you have not personalized the request form

David_Cox

Copy the dataport to a new number 50087 and name setting the request form to true, add this to a Menu > Periodic Activities for manual testing and later for Customer support if any errors happen, any changes to code just keep the two dataports inline

David

jversusj

thanks...

i don't really have the objects to spare to keep alternate copies, so i think Belias' approach is more along the lines of what i'm after. we have not personalized the req. form - i was just looking for a way to suppress the req. form when calling from the CU. now to try that approach.

Thanks again to you both!

jversusj

okay, i tried the following code

DP50088.FILENAME(sFilePath);
DP50088.IMPORT(TRUE);
DP50088.RUNMODAL;
CLEAR(DP50088);

this worked fine with my dataport as is (use request form = No), but as soon as i changed the use request form to Yes, my CU call was once again popping the req form - which is not the ideal result.

oh well, i guess there is no magic bullet for this?

DenSter

Huh.... that is weird.... doing DATAPORT.RUN, you have the option to suppress the request form, but it's not there when you use a dataport variable... That is truly annoying...

David_Cox

DenSter wrote:

Huh.... that is weird.... doing DATAPORT.RUN, you have the option to suppress the request form, but it's not there when you use a dataport variable... That is truly annoying...

One more option might be to set the dataport properties to Import the same file path and name every time then in your codeunit rename the new files and import them.

Set the dataport to Import = Yes and add the FileName in the Properties, then in your codeunit:

//Check to see if there is a file that did not import and try to import it
//This is the filename from the dataport properties
TempFileName := 'C:\Temp\Temp.txt';
IF FILE.EXISTS(TempFileName) THEN BEGIN
      DATAPORT.RUNMODAL(50089,FALSE);
      //If we are here then the file imported without error 
      //Add some checking code here before deletion       
      FILE.DELETE(TempFileName);
      //or rename to History
      FILE.RENAME(TempFileName,HistoryFileName);
end;

//NewFileName := 'C:\Temp\12345.txt'; this is your sFilePath
NewFileName := sFilePath;
//Create a HistoryFileName here if Required
// Pick up our new file
IF FILE.EXISTS(NewFileName) THEN
   FILE.RENAME(NewFileName,TempFileName);

IF FILE.EXISTS(TempFileName) THEN
      DATAPORT.RUNMODAL(50089,FALSE);

//If we are here then the file imported without error 
//add some checking code here before deletion       
FILE.DELETE(TempFileName);
//or rename to History
FILE.RENAME(TempFileName,historyFileName);

David :-k

Belias

DenSter wrote:

Huh.... that is weird.... doing DATAPORT.RUN, you have the option to suppress the request form, but it's not there when you use a dataport variable... That is truly annoying...

](*,) didn't remember this...what a shame!

*As david cox said before

Copy the dataport to a new number 50087 and name setting the request form to true, add this to a Menu > Periodic Activities for manual testing and later for Customer support if any errors happen, any changes to code just keep the two dataports inline

Anyway, it's not compulsory to have a test object in customer's licence range...you can use dataport 99999 for example...is it a problem?

jversusj

Belias wrote:

DenSter wrote:

Huh.... that is weird.... doing DATAPORT.RUN, you have the option to suppress the request form, but it's not there when you use a dataport variable... That is truly annoying...

](*,) didn't remember this...what a shame!

*As david cox said before

Copy the dataport to a new number 50087 and name setting the request form to true, add this to a Menu > Periodic Activities for manual testing and later for Customer support if any errors happen, any changes to code just keep the two dataports inline

Anyway, it's not compulsory to have a test object in customer's licence range...you can use dataport 99999 for example...is it a problem?

actually, i am the customer.

our license has granules for development (i can write code behind tables and in CU and stuff) but i am limited by our object range.

@David
the whole point of this exercise was to create a dataport that i can call from a Codeunit with a programmatically defined filename without launching the request form and also be able to RUN the dataport from the object designer with request form for testing when issues are discovered. i think by defining the file name in the properties, i would still have an issue attempting to run the DP from the object designer, would i not?

thanks to all. this is a minor headache really. the workaround is changing the use request form property manually (recompile) when testing is required. not perfect, but ideally once the integration is complete there will not be more testing!

David_Cox

jversusj wrote:

@David
the whole point of this exercise was to create a dataport that i can call from a Codeunit with a programmatically defined filename without launching the request form and also be able to RUN the dataport from the object designer with request form for testing when issues are discovered. i think by defining the file name in the properties, i would still have an issue attempting to run the DP from the object designer, would i not?

If there was a Problem when the Codeunit run it would be one of two things, first being that the directory or the file was not available due to a network issue or someone deleting the directory, running the dataport directly would give an error saying either the 'Drive or Directory does not exist' or the 'file does not exist', both you can investigate.

Second would be the dataport failed to import the file, the codeunit would have already renamed the file if the import was aborted due to an error, so running the dataport directly would give you a system or navision error, or it could just import the file as the file may have been locked by a virus scan or someone already had it open on the first attempt, you could deal with a system or navision error, you would not need to select the file from the request form.

It really depends on how good the data is you are importing and how many times is it likely to fail, so the trade off is simple have to reset the request form everytime a file fails, or you import with a predefined filename without the request form, and only checking a couple of things when it fails.

I did run a test before posting the code and it all went fine without the request form, but it is a work around that could move the file to a history folder as well your call

David

jversusj

David Cox wrote:

jversusj wrote:

@David
the whole point of this exercise was to create a dataport that i can call from a Codeunit with a programmatically defined filename without launching the request form and also be able to RUN the dataport from the object designer with request form for testing when issues are discovered. i think by defining the file name in the properties, i would still have an issue attempting to run the DP from the object designer, would i not?

If there was a Problem when the Codeunit run it would be one of two things, first being that the directory or the file was not available due to a network issue or someone deleting the directory, running the dataport directly would give an error saying either the 'Drive or Directory does not exist' or the 'file does not exist', both you can investigate.

Second would be the dataport failed to import the file, the codeunit would have already renamed the file if the import was aborted due to an error, so running the dataport directly would give you a system or navision error, or it could just import the file as the file may have been locked by a virus scan or someone already had it open on the first attempt, you could deal with a system or navision error, you would not need to select the file from the request form.

It really depends on how good the data is you are importing and how many times is it likely to fail, so the trade off is simple have to reset the request form everytime a file fails, or you import with a predefined filename without the request form, and only checking a couple of things when it fails.

I did run a test before posting the code and it all went fine without the request form, but it is a work around that could move the file to a history folder as well your call

David

thanks - i'm not sure i really understand what you are suggesting, thus my original response.

i have a warehouse mgmt system dropping files into a directory. these files are dropped off every minute, and each file will have a different file name. my codeunit rolls through the directory looking for specific file extensions. when it finds a file extension it is looking for, it will then call the appropriate dataport to load that file (there are actually 4 different dataports). it will then copy the file to an archive directory and then delete the original. further, the codeunit then calls a series of processing reports to act on the data imported by the dataport. it will roll through the dataport and then 3 subsequent processing reports, hence the occasional need to step-test. by running from my CU, the system will pull the data in, process it, post it, and archive it. sometimes i need to run each step at my speed, checking and validating all is well along the way.

i think you are proposing that i would tell the dataport to always use a particular file name. i would then need to add a step to my codeunit to rename the file to what the DP is expecting? then i could delete it later? is that what you mean?

i'm not sure i want to go through all of that just for this testing phase.

David_Cox

jversusj wrote:

i think you are proposing that i would tell the dataport to always use a particular file name. i would then need to add a step to my codeunit to rename the file to what the DP is expecting? then i could delete it later? is that what you mean?

i'm not sure i want to go through all of that just for this testing phase.

That is correct, but the easiest way might be just to purchase some extra dataports in your licence for support or look to see if there are any no longer required, and just copy the ones that do not show the request form, re-enable the request form and add the dataports to a menu for quick support reasons.

David