How to call LlPrintResetProjectState when using a DataProvider in .NET

I would like to know if it is possible somehow to call LlPrintResetProjectState when using a data provider. I have read about the AutoMasterMode but I only have one table in my datasource. This table contains a field which indicates whether a ResetProjectState should occur.

I am currently looking into the AutoDefineNewLine event, which allows me to query the data before llPrint is called. I am not sure if this is the right place, would appreciate if someone can confirm this or direct me in the right direction.

Also, the field which indicates the ResetProjectState (yes/no) is not used within the project itself as a field. So I need to pick that up from the “current” record in the datasource. How do I do that?

Thanks for any suggestions!

Hi Jos,

I would ask another question: “How can I change my data source to support AutoMaster Mode together with the ListLabel component and the openedge data provider?”.

The answer is quite simple. Create another table like “document” or whatever you name it. Have a unique key like a sequence or a guid in this table. Add this field to your current table and put an index on it. Your “flag” starts a new group of records since you wanna have a project reset. The group would be a document now.

define temp-table ttDocument no-undo
  field DocumentId as integer
  index pix is primary unique DocumentId.

define dataset ds for ttDocument, <your table>
   data-relation ds for ttDocument, <your table> relation-fields (DocumentId,DocumentId).


oLL:DataSource     = oProvider.
oLL:DataMember     = "ttDocument".
oLL:AutoMasterMode = LlAutoMasterMode:AsVariables.
oLL:ForceSingleThread = TRUE.


Best regards,
Thomas Wurl

1 Like

Hi Thomas, that’s an interesting thought. I will explore it. The reason I am looking for calling LlPrintResetProjectState “manually” (without AutoMasterMode) is that I do not want to modify all existing reports. Or maybe I am mistunderstanding your suggested approach: Are you saying that I just need to add it to the dataset without modifying the report?

But I would still like to (at least) capture the event when the master table changes as I need to do some other work with the LlPrintResetProjectState. Is there an event that I can subscribe to?

Hi Jos, I don’t think that you are able to use it without modification of your report. You have two tables now (ttDocument registered as variables) and my understanding is that you have to have a report container for that. You also need to have a relation based query for “your table”. So “your_table” needs to be a sub-element of ttDocument. You have to try what happens …

I don’t know if there is an event when the master record changes. I also don’t know if and how to access column values of this record. All I can say is, that my data provider doesn’t know what LL is doing with the data. So the only place would be the LL component.

A good moment might be the AutoDefineVariable event. However, due to optimizations you won’t be able to access any data that is not used in the report as it will not be queried from the database at all. Workaround might be to still use the column but without printing it, e.g. SetVar(“dummy”, YourField, false). However this feels like workarounding our stuff to get something working as it used to - if you really need all this special handling (for whatever reason), it might be easier to stick to the old approach.

Hi Thomas, I tried your suggestion but when I open the designed, I can see ttDocument within the variables section but does not show anywhere, not in the variables nor the fields section. Is there any need to register that relation within the OpenEdgeDataProvider or am I mssing something. It looks like the dataset is not transferred with relations to LL.

EDIT: Found what I was missing. Needed to put correct (unique) indexes on the tables in the dataset to that the OpenEdgeDataProvider sees them as 1 to 1 or 1 to many.

Hi Jochen, the reason that I want to do “my stuff” during a ResetProjectState() is mainly that I need to implement and option that page numbers are NOT reset to 1 each time a ResetProjectState() occurs. So instead of using the build-in page nr function, I am using my own variable which I set after doing a ResetProjectState(). So before I query the nr of pages and afterwards, I am setting the “start” value to reflect the nr of pages already printed.

I now have the ResetProjectState implemented through the AutoMasterMode, so my last (?) hurdle would be to solve the page numbering issue.

Maybe there is another way in doing this? Thanks.

How about a completely custom page counter then? You could easily use the AutoDefineNewPage event to increment your page count every time and simply pass it as variable. Then use this variable wherever you need the page number.

The event handler could look like something along these lines:

private int _pageCount;

private void LL_AutoDefineNewPage(object sender, AutoDefineNewPageEventArgs e)
    if (!e.IsDesignMode)

    (sender as ListLabel).Variables.Add("CustomPageCounter", _pageCount);

Thanks, that will remove the need for ResetProjectState() !

1 Like

As an addition to this post: Managing the page numbers using AutoDefineNewPage() has it’s quircks as I found that this function also gets called when a ResetProjectState() is triggered. So if you do your own page numbering, it may get confused.

Interesting, my R&D on the problem also shows that there is a function which is triggered whenever a ResetProjectState() occurs. This function is QueryFileNameForExportJob. (Strangely enough, I cannot find any documentation on this function within the help file.)

I am now using this function to manage my custom page numbering (allowing me to e.g. specify an offset page number as well as implement continuous page numbering across ResetProjectState().
As a suggestion (unless I missed it): Having a native LL properties to set ContinuousPageNumbering and StartPageNumber would be a good addition to LL. :wink:

1 Like

You stumbled upon a yet undocumented feature here. The event can be used to split export results at a LlPrintResetProjectState() that would otherwise be combined to one file. That way, you can have a new PDF for each part of your printing job. Save to use for your purpose.

Hi Jochen, tnaks for confirming that I stumbled across something thar will fit my purpose. :wink: Regards. Jos

© combit GmbH