How to find the export target selected by a user in .NET

Is there a way in .NET to find out which export target the user has selected in LlPrint?

Hi Jos!

you can get the export destination within the very first DrawPage event via LlPrintOptionString.Export. The code looks very simple (C#):

private void BtnPrint_Click(object sender, EventArgs e)
{
    //Create DataSource
    DataSource();

    //Trigger DrawPage-Event
    LL.DrawPage += LL_DrawPage;

    //Execute Print
    LL.Print();
}

private bool _hasReadExportFormat;

private void LL_DrawPage(object sender, DrawPageEventArgs e)
{

    if (!_hasReadExportFormat)
    {
        //Get Export Destination
        LL.Core.LlPrintGetOptionString(LlPrintOptionString.Export);
                  
        _hasReadExportFormat = true;
    }
}

Hi Christian, thanks for the example code.

That works indeed after start of print, but I would actually want to query the export destination without starting the print. I used to do this when I did not use a dataSource by calling LlPrintOptionsDialog which would present the user with the print dialog without running the report directly afterwards.

Is there an equivalent for this when using a DataSource?

I cannot seem to get this working. LlPrintOptionsDialog does not work as LL will tell me I am trying to use a print function without starting a printjob.

So I guess, I will need LL.Print() and intercept before the actual printing process starts.

Any suggestions?

I just learned (yes I am still learning!) that there is also QueryFileNameForExportJob handler. That will allow - similar to the construct outlined by Christian, capturing of the selected export option the moment when the user clicks on the “Start” button.

Now my next challenge is: How to I stop de print function. My goal is to let the user select the export options, save them as a printconfiguration and re-apply this later when the report is run (by a different process).

How can I achieve “stopping” the actual print?

EDIT: oLL:Core:LlPrintAbort(). does the trick!

Unfortunately you haven’t done this the way it was supposed to.

You are right, the print process can be aborted using oLL.Core.LlPrintAbort.

Hi Christian, can you eloborate on your remark: “Unfortunately you haven’t done this the way it was supposed to.”?

@crauchfuss was probably referring to the way you’ve been doing this before - the standard being opening the print dialog after starting the print job. I understand you’ve got everything working now :slight_smile:?

Still not fully there, but advancing… Thanks.

1 Like

Hi Jos,
why don’t you do this the way you did this before with the dll?
I’m also quite sure there must be something possible with LL.core.

When you actually want to print, export then you switch to the LL.Net component and the data provider.
Or you write your own export options dialog in Progress.

Best regards,
Thomas Wurl

1 Like

Hi Thomas, maybe because I do not like to mix technologies. It’s a nerd thing i guess… :wink:
But the QueryFileNameForExportJob event combined with oLL.Core.LlPrintAbort() did the trick.

1 Like

As a follow up on this post, I noticed that the order in which events are executed is different for LIST type projects and LABEL type projects. (I haven’t looked into CARD projects).

In my application am getting the data in to a temp-table. For this reason I am overriding GetData in the OpenEdge dataprovider with my own GetDataEvent.

I am also using QueryFileNameForExportJob as I want to ask the user for an output destination before getting the data. For LIST projects this works fine:

  1. PrinterDialog shows
  2. QueryFileNameForExportJob event is triggered
  3. GetDataEvent is triggered to retrieve the data.

However, for LABEL projects, the order is

  1. GetDataEvent is triggered to retrieve the data (so before the user can select an output destination)
  2. PrinterDialog shows
  3. QueryFileNameForExportJob event is triggered

Is there any way to influence this? Is this sequence of events dictated by List&Label or is this implemented in the OpenEdge data provider?

Thanks.