Options

how to use progress indicator in report

tneurbtneurb Member Posts: 9
Hi all Expert .Can u Tell me how to use Progress Indicator.
Where the Trigger can i put the code.

Comments

  • Options
    AlbertvhAlbertvh Member Posts: 516
    Hi tneurb

    do the following
    declare 3 variables
    window of type dialog
    TotalRec of type integer
    CurRec of type integer

    in OnPreDataItem section
    window.OPEN('Processing @');
    TotalRec := COUNT;
    in AfterGetRecord section
    CurRec := CurRec + 1;
    window.Update(1,ROUND(CurRec / TotalRec * 10000,1);
    in OnPostDataItem

    This should do the trick :wink:
    window.CLOSE;
  • Options
    tneurbtneurb Member Posts: 9
    thank you very much
  • Options
    ShenpenShenpen Member Posts: 386
    Note: you can use COUNTAPPROX instead of count, it is faster and was created exactly for this.

    Do It Yourself is they key. Standard code might work - your code surely works.
  • Options
    DenSterDenSter Member Posts: 8,304
    yeah you can save a whole milisecond on that one line of code!! :mrgreen:
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    Shenpen wrote:
    Note: you can use COUNTAPPROX instead of count, it is faster and was created exactly for this.

    Countapprox only works differentley from COUNT if you have SQL, I think
    COUNTAPPROX (Record)
    Use this function to obtain an approximate count of the number of records in the table, for example, for updating progress bars or displaying informational messages.

    Number := Record.COUNTAPPROX
    Record

    Data type: record

    Refers to the table to be counted.

    Number

    Data type: integer

    The number of records in the table.

    If a filter has been set on the record, this function will behave exactly as the Record.COUNT function.

    Comments
    The count is approximate because it uses statistical information maintained by SQL Server, which is not kept precisely in synchronization with modifications to the table and is not under transaction control. However, it is much faster to use this information than to perform an accurate record count under transaction control, especially when there is a large number of records in the table.

    Example
    This example shows how to use the COUNTAPPROX function. The statement:

    Number := Customer.COUNTAPPROX;

    assigns the approximate number of records in the Customer table to the Number variable.
  • Options
    DenSterDenSter Member Posts: 8,304
    Key quote:
    If a filter has been set on the record, this function will behave exactly as the Record.COUNT function.
    Modifying one line of code is usually not going to make much of a difference, it's repeated statements and inefficiencies in processing code that make a difference.

    Most of the time, a progress bar slows down the process because of the constant updating. Executing one line of code takes almost nothing in terms of time, but for some reason repainting the dialog box does. If one of your reports is slow because of a progress bar, you need to limit the number of updates, say once every 100 updates, or only update every so many seconds.
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    From the navision reminders:

    NewTime := TIME;
      IF (NewTime - OldTime > 100) OR (NewTime < OldTime) THEN BEGIN
        NewProgress := ROUND(RecordNo / NoOfRecords * 100,1);
        IF NewProgress <> OldProgress THEN BEGIN
          Window.UPDATE(1,NewProgress * 100);
          OldProgress := NewProgress;
        END;
        OldTime := TIME;
    
  • Options
    ShenpenShenpen Member Posts: 386
    Yes, it is true. I used to use Dialogs to in a MyDialog.UPDATE(1,MyItem."No.") - style for all data migration & repair programs just to avoid freezing finsql.exe and I found in awe that their performance bottleneck is not reading the database, but updating the dialog. Updating progress bars or dialogs just on every 100 records sounds like a good idea.

    (Fun stuff: if you want to write a really _slow_ program, call COUNT on every record, updating the progress bar instead of storing the record count :D A coworker once did it by mistake, and later on when I corrected it the client was quite surprised that a report can be made 10 times faster with only 30 seconds of hacking :D:D:D )

    Do It Yourself is they key. Standard code might work - your code surely works.
  • Options
    DenSterDenSter Member Posts: 8,304
    Hey maybe that will mke your customers happy... Make their stuff work really slow at first and then go in later and make "improvements" :)
  • Options
    ara3nara3n Member Posts: 9,256
    Another reason to follow your approch denster is to improve the performance gradually. As they do business, the database starts to grow and the reports run longer and longer, so if you make the report run slow at the beginning and gradually improve the performance, they won't complain 5 years down the road. :D
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    If you design a new report, performance is part of the initial design. 8)

    It is not something you do afterwards. [-X

    This is why so many navision customers are dissapointed. :|
  • Options
    ara3nara3n Member Posts: 9,256
    I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    SavatageSavatage Member Posts: 7,142
    Albertvh wrote:
    Hi tneurb

    do the following
    declare 3 variables:
    window of type dialog
    TotalRec of type integer
    CurRec of type integer

    in OnPreDataItem
    window.OPEN('Processing @1@@@@@@@@');
    TotalRec := COUNT;
    
    in AfterGetRecord
    CurRec := CurRec + 1;
    window.Update(1,ROUND(CurRec / TotalRec * 10000,1);
    
    in OnPostDataItem
    window.CLOSE;
    

    window.Update(1,ROUND(CurRec / TotalRec * 10000,1));

    1 more parentasis 8)
  • Options
    DenSterDenSter Member Posts: 8,304
    Maybe we should build a dynamic performance enhancement add-on that calculates per how many records it updates the dialog depending on the number of records in the database :)
  • Options
    kinekine Member Posts: 12,562
    Something like Aurora for Vista... :-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Options
    SavatageSavatage Member Posts: 7,142
    DenSter wrote:
    yeah you can save a whole milisecond on that one line of code!! :mrgreen:

    I was just reading this post again - C'mon that's funny =D>
  • Options
    themavethemave Member Posts: 1,058
    Savatage wrote:
    DenSter wrote:
    yeah you can save a whole milisecond on that one line of code!! :mrgreen:

    I was just reading this post again - C'mon that's funny =D>
    I tought it was pretty funny :lol:
  • Options
    themavethemave Member Posts: 1,058
    ara3n wrote:
    I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.
    Ah, but 5 or 10 years from now they will have upgraded to a new version of Navision, and it will be much slower then the prior version, so you will need every trick you can think of to help with speed. :wink:
  • Options
    ara3nara3n Member Posts: 9,256
    themave wrote:
    ara3n wrote:
    I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.
    Ah, but 5 or 10 years from now they will have upgraded to a new version of Navision, and it will be much slower then the prior version, so you will need every trick you can think of to help with speed. :wink:

    I give up. :-#
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    themavethemave Member Posts: 1,058
    ara3n wrote:
    themave wrote:
    ara3n wrote:
    I agree and the report will run at optimal, it's just you add window.update for every record, or record.count for every update, These additional functions will mimic how fast the report will run 5 or 10 years from now, and gradually you remove these functions. This whole thing was meant as joke, don't take it serously.
    Ah, but 5 or 10 years from now they will have upgraded to a new version of Navision, and it will be much slower then the prior version, so you will need every trick you can think of to help with speed. :wink:

    I give up. :-#
    I am only joking :D
  • Options
    ara3nara3n Member Posts: 9,256
    I was too :P
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    themavethemave Member Posts: 1,058
    We could start a new thread titled
    "We just finished upgrading and now Dynamic Nav is so slow" [-o<
  • Options
    KowaKowa Member Posts: 918
    If you add
    if CurRec MOD 10 = 0 then
    window.Update(1,ROUND(CurRec / TotalRec * 10000,1));

    the window is updated once every 10 records. That will save more than just a millisecond on tables with many records. :wink:
    Kai Kowalewski
  • Options
    fufikkfufikk Member Posts: 104
    For long running reports as an "upgrade" I sometimes put info with estimated execution time. It doesn't do much but its nice to look at :)
  • Options
    dohertykdohertyk Member Posts: 94
    Savatage wrote:
    Albertvh wrote:
    Hi tneurb

    do the following
    declare 3 variables:
    window of type dialog
    TotalRec of type integer
    CurRec of type integer

    in OnPreDataItem
    window.OPEN('Processing @1@@@@@@@@');
    TotalRec := COUNT;
    
    in AfterGetRecord
    CurRec := CurRec + 1;
    window.Update(1,ROUND(CurRec / TotalRec * 10000,1);
    
    in OnPostDataItem
    window.CLOSE;
    

    window.Update(1,ROUND(CurRec / TotalRec * 10000,1));

    1 more parentasis 8)

    Why is it that the "Cancel" button doesn't work?

    However, pressing the escape key does?

    Is there an event that I need to be testing for? Or is it supposed to be handled by the dialog itself?

    Thanks in advance,

    Kevin
  • Options
    SavatageSavatage Member Posts: 7,142
    My Cancel button Works :-k
  • Options
    MbadMbad Member Posts: 344
    Using count or countapprox sux(lol Savatage). Using the updating window when running anything sux your performance dry. If you cant avoid these do only update every 1000 or 10000 records/cycles.
Sign In or Register to comment.