Very slow performace to edit great view - InfoPath Dev
in

InfoPath Dev

Very slow performace to edit great view

Last post 08-10-2013 11:51 AM by Patrick Halstead. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • 08-09-2013 10:45 AM

    • sgssergio
    • Not Ranked
    • Joined on 08-08-2013
    • Buenis Aires, Argentina
    • Posts 1

    Very slow performace to edit great view

    Hi all:

    I have a infotpath 2010 form with a form with a custom table (using a custom xsl ). This form I use in Desktop mode (non browse-enabled).

    My problem is when I to edit any field of the table, the firt time the edit performance  is succesful, but changing to other text field the performance degrade very much. The infopath is hanged during about 2-3 second upto permit edit the new field. The user experiencie is very bad.

    I monitoring the I/O rate and detect that the infopath acces a lot to the Registry and temp file for each edit operation.

    Example:

    xml infopath form  size: 230 Kb.

    I write one (1) character in a text field into one table and the Microsoft Sysinternal Process Monitor register ore than 200 I/O acces (the most case write operations) and about 200 acces to the registry.

    Is posible configure the infopath to cache the edit data and only flush the data to the disk few times?

    Is posible to instruct the infopath (in the config or using code) to disable de autoupdate del forma in each text field edit?

    What is the recomendation to improve the editing performance in Infopath 2010 forms? 

    Best Regards

     

     

    Filed under: ,
  • 08-10-2013 11:51 AM In reply to

    Hi SGSSergio and welcome!

    Edit performance for the filler (desktop) is a function of the size of the view, number of window controls in it, and rules triggered when tabbing out of fields.

    We have done forms with large tables (200 rows x 20 columns) and they work fine in the InfoPath client but if you add rules and have updates, performance can degrade.

    In addition, if you have a large dropdown in the table, that will create a lot of window controls (one for each value) because it multiplies those controls for each row where the dropdown exists.

    If you have a large table, a simple thing to do is to implement paging - in other words, don't show all rows. See attached sample.

    Another thing you should do is inspect the rules to make sure it isn't running a lot of logic to update fields.

    Thanks,

    Patrick Halstead
    Project Manager at Qdabra
Page 1 of 1 (2 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.