« Display a Geometry Debugging Point in the Model | Main | Temporary Transaction Trick Touchup »

November 01, 2012

Comments

Hi Jeremy,

I have implemented this pattern before and I noticed that one of my CPU cores was running at 100% when using e.SetRaiseWithoutDelay(). As you know, this is because Revit is constantly raising the Idling event. I would only suggest a minor change to the code as below:

if( !TaskContainer.Instance.HasTaskToPerform )
Threading.Thread.Sleep(1000);
return;

Though, this would increase latency by a second. You can try different values of sleep and see how it affects the CPU usage.

Dear KR,

Thank you for your valid and helpful suggestion.

It all depends on your needs, of course: immediate response to the Revit task request versus overall load on the CPU.

When in heaven's name are we ever going to be allowed to keep our cake and eat it too?

Cheers, Jeremy.

Jeremy,

I was hoping that we could do more with the ExternalEvent when it was introduced with 2013. As you know, it does require the user to be active in order to be raised. It would be nice if this was not the case. Hopefully in 2014.

KR

Dear KR,

What is 2014? Never heard of it!

I do not expect any changes in the external events at all.

If you want any, please make sure a wish list item is submitted.

Cheers, Jeremy.

Hello, KR.
I also don't think that ExternalEvent would help. External Events are internally still based on Revit idling
In my opinion the only correct subscribing and unsubscribing idling event can avoid CPU loading.

Regards, Victor.

Hi all,

there are sitations where OnIdling event won't be fired.

Think of error or warning dialogs.
In fact, each dialog which remains opened will block the event.

Additionally, there are types of views in which no transactions can be performed, for example all 3D views (excepting "{3D}") plus list views.

If you want Revit to show an element, think of handling the "Looking for good view" dialog which needs to be closed before proceeding, anyway.

Best regards,
Rudolf

Dear Rudolf,

I think you do not mean *all* 3D views except "{3D}", only all *perspective* views.

Cheers, Jeremy.

Hi Jeremy,

yes, there are some sorts of Views which prevent the user from executing commands.
Perspective views, for example.

Buttons are greyed out/disabled if such a view is the active one (this is also version depending, e.g. in Schedule Views, you can execute commands in 2013 but not in 2012).

Thus, the service must check if any command can be performed at all.
Or think about the zero document environment...


Cheers,
Rudolf

Dear Rudolf,

Thank you for the valuable warnings.

Also, please be aware that the API can very well be active and used in a zero document context:

http://thebuildingcoder.typepad.com/blog/2011/02/enable-ribbon-items-in-zero-document-state.html

Cheers, Jeremy.

Hi Jeremy,

I know very well that API may be *active* in zero document environment.
But of course there is no document database to work with, so there is no much sense in performing commands on this level, except opening files or returning some application level data, e.g. Revit product info, version etc., of course.


Best regards,
Rudolf

Dear Rudolf,

You could open an unlimited number of *background* documents. That should give you enough to play with. Who needs a user interface, or a human user, for that matter? Just another source of errors and confusion. :-)

Cheers, Jeremy.

Hi Jeremy,

I've done *both* so far:
driving Revit from outside (11/12/13) and creating/opening (family) documents in the background.

When editing documents, it may happen that user interaction is needed.
We cannot handle all possible errors by the failure API (many, many BuiltInFailure definitions, and think about overriding the default settings accidentally; in fact we could suppress even severe errors without the user even noticing it).
So of course I who needs a user if you could do the job using a script ;-)
But no, noo, there will always some dialogs which must be handled by user.
Auto-clicking them, will be difficult because of localization issues and because of the fact that Revit (and its plug-ins) may use a mixture of WPF and WinForm controls. See UIAutomation for further information ;-)


Cheers,
Rudolf

Hi
This program is in revit 2013? and we should setup the revit sever 2013?

Hi!!

I'm really want your help!!!!!!

I saw your blog (url:http://thebuildingcoder.typepad.com/blog/2012/11/drive-revit-through-a-wcf-service.html). Downloading the code, I installed the Revit 2013 in window sever2012 R2, Anything I tried!!!!!

But there is a problen "RevitExternalAccessClient.exe cannot connect Revit & revit has no response"

like this:http://localhost:56789 is a incorrect web site, Reject connection.127.0.0.1:56789. System.Net.Exception cannot connect to sever......................................................................

Can You Help Me???? PLEASE!!!!!!

Dear Albert,

What we present here is not so much a program as a programming solution.

You can implement your own solution based on this in any version of Revit that you like. You do need it to support the Idling event or external events, though. Revit 2013 or anything newer than that is fine.

Revit Server is not required. This has nothing whatsoever to do with Revit Server.

Cheers, Jeremy.

Dear Albert,

Please do not yell.

Thank you.

No sorry, I cannot provide much advice on this, beyond underlining that the example you refer to is a programming example.

Mainly, it presents source code that you can reuse in your own programming efforts.

You can implement your own solution based on it in any version of Revit that you like.

You do need it to support the Idling event or external events, though. Revit 2013 or any later version is fine.

I hope this helps.

Cheers, Jeremy.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)

Jeremy Tammik

AboutTopicsIndexSource