Properties Dialog doesnt accept input when commit transaction durig Idle event

Properties Dialog doesnt accept input when commit transaction durig Idle event

boostyourbim
Advocate Advocate
1,408 Views
9 Replies
Message 1 of 10

Properties Dialog doesnt accept input when commit transaction durig Idle event

boostyourbim
Advocate
Advocate

This idling event is registered on startup. As expected, it sets the active view's Title on Sheet when Revit goes idle. (this is just a test case, my real application does other things)

 

The problems as shown in the screencast is that it is now impossible to use the Revit Properties Dialog. When I try to type text input (like to change the height of the wall) Revit does not accept the input. When I try to select from a drop-down list, the list does not function properly.

 

How can I modify the document on Idle and also have the Properties Dialog continue to work?

 

 

        public Autodesk.Revit.UI.Result OnStartup(UIControlledApplication application)
        {
            application.Idling += Application_Idling;
        }

        private void Application_Idling(object sender, IdlingEventArgs e)
        {
            UIApplication uiapp = sender as UIApplication;
            Document doc = uiapp.ActiveUIDocument.Document;

            using (Transaction t = new Transaction(doc, "set date"))
            {
                t.Start();
                doc.ActiveView.LookupParameter("Title on Sheet").Set(DateTime.Now.ToString());
                t.Commit();
            }           
        }
0 Likes
1,409 Views
9 Replies
Replies (9)
Message 2 of 10

boostyourbim
Advocate
Advocate
0 Likes
Message 3 of 10

Revitalizer
Advisor
Advisor

Hi Harry,

 

may it be that there are lots of "set date" transactions in the undo stack?

OnIdling event is fired often, you may see the displayed seconds changing.

 

I think it is a timing problem.

Your manual transaction is made invalid by the onIdling transaction, it just overtakes you when typing your manual input.

 

So what about integrating a delay?

Also, if your timestamp could be rounded to minutes, you could compare the previous value with the new one and only set the parameter if there is a difference, omitting unnecessary transactions.

 

 

 

Revitalizer




Rudolf Honke
Software Developer
Mensch und Maschine





0 Likes
Message 4 of 10

boostyourbim
Advocate
Advocate

Hi - I don't understand the idea that "Your manual transaction is made invalid by the onIdling transaction"? What is the "onIdling transaction"? If I remove the transaction start & commit from my code there is an error "Attempt to modify the model outside of transaction." Autodesk's documentation says:

 

"Handlers of this event are permitted to make modifications to any document (including the active document)...In order to change a document, you must begin a new transaction for that document"

 

In any case, my example of setting this parameter is for testing & demonstration purposes. I do need to commit a transaction every time Revit goes idle and it seems like an Autodesk bug that the Properties Dialog in unusable in this situation.

0 Likes
Message 5 of 10

Revitalizer
Advisor
Advisor

Hi again,

 

what I wanted to say is:

 

Each entry in the undo stack represents a transaction, either done by the user or by code.

 

If you change a parameter manually, the transaction is committed when you press the Apply button or when you move your mouse pointer from property sheet to a view.

That manual movement for committing may take some time.

 

The transaction in the Application_Idling event (the "onIdling" transaction), on the other hand, will be committed much faster: when Revit executes the t.Commit(), that means nearly instantly.

 

It's just a man versus machine thing, your code is faster than you.

Your changes are never committed.

 

 

Revitalizer

 

 




Rudolf Honke
Software Developer
Mensch und Maschine





0 Likes
Message 6 of 10

boostyourbim
Advocate
Advocate

So any time an Idling transaction is committed, Revit is going to "reset" the Properties dialog to its last state and any in-progress entry will be lost.

So if I am changing the value of an instance parameter from "hello" to "goodbye" and I've typed "good" and then the idle event triggers and commits its transaction, Revit will reset the text box value to "hello".

 

If that's the reality, then a solution could be to know if the Properties dialog has focus and, if it does, do not run the idling event code. Is there a Revit event that fires when the Properties dialog gets focus? Or use Windows Automation API?

0 Likes
Message 7 of 10

Revitalizer
Advisor
Advisor

Hi Harry,

 

afaik, there is no such event.

 

For the Sheet's title, would it be sufficient if the TimeStamp is set only

 

  • when a user opens the Sheet?
  • when the file is about to be saved/synchronized?

 

In the first case, you could use UIControlledApplication.ViewActivated - if the ViewActivatedEventArgs.CurrentActiveView is your Sheet, update the TimeStamp.

 

I don't see a reason for a continuous update - it fills the undo history with a lot of transactions, making it difficult for the user to rollback any other transaction.

 

 

 

Revitalizer




Rudolf Honke
Software Developer
Mensch und Maschine





0 Likes
Message 8 of 10

Anonymous
Not applicable

Hi Harry,

 

Couple thoughts on this issue.

1. If you can, have you tried moving this code into an external event and raising it from the idling event? (if it's not already pending)

2. Could you potentially (additionally) implement a delay counter?  (would allow you to tune the frequency with which the event is raised from the idling event)

 

-Ken

0 Likes
Message 9 of 10

boostyourbim
Advocate
Advocate
Thanks Ken. Have already done #2. Will consider trying #1.
0 Likes
Message 10 of 10

jeremytammik
Autodesk
Autodesk

Thanks very much to Revitalizer and Ken for their insightful advice.

 

Just for your information (and my own forgetfulnes -- hhrrrmm, tracking), this issue has also been reported in ADN case 13899743 [Conflict between Idle event and Properties Palette in Revit].

 

I agree with the analysis discussed above and would suggest using an external event if possible.

 

In fact, I suggest ALWAYS using an external event rather than an Idling event, if possible:

 

http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.28

 

Especially -- Replacing an Idling Event Handler by an External Event: 

 

http://thebuildingcoder.typepad.com/blog/2013/12/replacing-an-idling-event-handler-by-an-external-ev...

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

0 Likes