Journal files and the API

[GuyR]

James,
I've started a new thread so we can get it right in the wishlist.And no limit, given there seems to be about 4 of us using the API:-)

Well I best get my wish in quick in-case they a limited to 3.

In absence of any form of API, we have for some time been using the journal to provide script control to repeating tasks.

We have found this works very well however, when the API was opened up we thought we would be able to run these scripts from an external command within Revit but this capability has not been enabled.

We already have an application written in VB which reads Microsoft project construction programs and links this to objects within a NavisWorks model and hides/displays these objects depending on their existence according to the program.

I know this would be something we could adapt to control views in Revit using MS project however, we need to be able to do this from within Revit via an external command.

Whilst it is technically feasible to do this through the journal file, it means exiting the program each time the script is to be run which adds to the time taken to complete our work.

I would like to be able to run all the journal scripts from within Revit using the API and I very much hope that this wish could be granted soon.

Reading this I get a couple of wishes:

1.. Journal scripting from the API (record/playback type functionality)
2.. Access to views and the turning off of individual elements from the API.
3.. Navisworks integration.

You can sort of do point 2 now. You can access views in a model via the API and I'm guessing you can then access the visibility categories and this would allow you to turn off groups of elements. How much granularity are you wanting? By element/ floor/ phase etc.

Guy

[James.Lupton]

James,
I've started a new thread so we can get it right in the wishlist.And no limit, given there seems to be about 4 of us using the API:-)



Reading this I get a couple of wishes:

1.. Journal scripting from the API (record/playback type functionality)
2.. Access to views and the turning off of individual elements from the API.
3.. Navisworks integration.

You can sort of do point 2 now. You can access views in a model via the API and I'm guessing you can then access the visibility categories and this would allow you to turn off groups of elements. How much granularity are you wanting? By element/ floor/ phase etc.

Guy

Guy

Item 1 - This would be great and thinking it through a bit further it would be a nice way to set up presentations of what can be done with Revit.

Item 2 - I would agree it seems it should be possible to do this even if it was just by changing the object phase from say "Foundations Off" phase to "Foundations On" phase.

The problem at present is that although in theory you should be able to control the visibility of objects, you Can't do anything with the view you have created without switching to manual. Using the Journal we can print the view, Export to Jpeg or run an AVI export over a limited number of slides out of the total number of slides required to progress along a path. We need to be able to do these things within the API.


Item 3 - I was actually wanting to ling MSproject and Revit. This allows us to sequence the construction activities in a gant chart and then extract the timing information to control element visibility. I would like to see more of the NavisWorks functionality as part of Revit but not necessarily through integration of NavisWorks

In terms of control of objects I really want to see better forms of view filtering to allow to break down views into limited groups of object depending on their defined parameters.

eg all foundations from a certain grade of concrete or walls with a certain finish.

Do you know any reason why the journal scripts may not have been released to the API?

I don't.

[Jeffrey McGrew]

Do you know any reason why the journal scripts may not have been released to the API?

My guess (and this is only a guess) is that has to do with the fact that using Journal files to script Revit is currently unsupported by Autodesk. While you can do it, the Revit folks will tell you to beware, for the next build or version of Revit could break your scripts with no warning.

Once I asked why that was. Basically it sounded to me that they don't want the burden (currently) of having to document and maintain something as direct as the Journal files, for it would greatly reduce the amount of flexibility and speed in regards to Revit's development if they couldn't make big changes.

With the .Net API, big changes to the Revit internals are possible without disrupting work people have done based upon it.

So until Autodesk decides to support Journal file use, or provides a scripting ability for Revit that wouldn't get in the way of it's development, I doubt we'll see it integrated into the API. But I'd love to be wrong about that...

[Danny Polkinhorn]

Do you know any reason why the journal scripts may not have been released to the API?
In addition to Jeffrey's comments, there's one major reason. Journal files only run while Revit is closed (by dropping on the icon), and External Tools using the API can only be run while Revit is open.

Honestly, I would rather see them expand the API than support Journal files within it.

[James.Lupton]

Danny

I would agree and I also understand the unsupported bit however, the things we do with the journal file are so simple but take a lot of work out of repetative tasks by using for next loops.

I can't see why even unsupported, te journal file commands can't be opened up to the API.

[Danny Polkinhorn]

Item 3 - I was actually wanting to ling MSproject and Revit. This allows us to sequence the construction activities in a gant chart and then extract the timing information to control element visibility. I would like to see more of the NavisWorks functionality as part of Revit but not necessarily through integration of NavisWorks

In terms of control of objects I really want to see better forms of view filtering to allow to break down views into limited groups of object depending on their defined parameters.James,

In thinking about this further, you can create and manage phases in Revit with the API. So you could link your MS Project file with your Revit project to set up phases by week or whatever. If there's some correlation in MS Project to the actual elements in Revit, you can assign the phase to the element as well. I'm not familiar with NavisWorks, but it sounds like you can already do some of what you want.

What you can't do, and I would agree that this should be high on the wishlist, is visibility control of views. So you could set up views and control what phase is shown, scale, etc. While this will be rather complicated just because of all the things that are controllable in a view, I think they should start working on it.

Hope that helps,

[James.Lupton]

Danny,

I agree the use of phases should give us a degree of control over what is and is not visible in the current view.

The ideal method would be to have the options of Phase, Category and Workset as different ways to control the visibility however, for the time being at least, phases should work.

The main problem however is that although there is some control over visibility, we can do nothing through the API to export the resulting view to an image file or AVI which is representative of the screen display created.

We can do this with the journal file where we can even set up sequential naming of the exported image file.

This is a very simple FOR - NEXT loop which runs much faster than any user could ever hope to achieve using manual control and therefore this saves a lot of time. On large projects we usually run this overnight.

We know that the journal commands are unsupported however they are available and as long as we take care to work on a copy of the model and not the master, any risks of using unsupported features can be managed successfully.

Even in an unsupported way with "a big health warning" attached, I would like to see the journal commands opened up to the API. Since the functionality is already in the software I can not perceive this to be an difficult feature to enable although I do admit I dont understand the extent of work involved in doing this.

[GuyR]

I would like to see the journal commands opened up to the API.

That's the whole API!!! As I understand it, the intention is to never expose the whole API. The exposed API we have now is just a subset of the full API so anything is possible. However, knowing the way Revit works using phases and worksets to control this would be asking for trouble I suspect.

How about API access to temporary hiding of elements either globally or per view and exporting of images/printing etc? Either that or a Naviswork plugin.

Guy

[James.Lupton]

That's the whole API!!! As I understand it, the intention is to never expose the whole API. Guy

Guy

If it is the whole API then it is already exposed therefore my argument is why do we have to use it in an inconvenient manner.

I can see no logic in this. Why should the user be prevented from using functionality which has been part of the system from day 1 in a more convenient way under the API.

Why not give us a call script feature in the API but stipulate that Autodesk can take no responsibility for how this feature is used.

I am sure it is already possible to write an API which could trash the model and I am equally sure that Autodesk will take no responsibility for that either (and I would not expect them to).

Could a Revit developer please try to explain the thinking behind this.

[GuyR]

If it is the whole API then it is already exposed therefore my argument is why do we have to use it in an inconvenient manner.

For exactly that reason ;-) As with most Revit functionality it's about what you're trying to achieve, and is the API in this form the best way to fullfil the goal.


I can see no logic in this. Why should the user be prevented from using functionality which has been part of the system from day 1 in a more convenient way under the API.

As I've explained, so Revit can't be ruined by every 2 bit programmer mucking around with it .Do you honestly want the AutoCAD situation?


Why not give us a call script feature in the API but stipulate that Autodesk can take no responsibility for how this feature is used.

In many ways the API is scripting functionality. Just not the record/edit you get with journal files.

I guess the point I'm trying to make is, construction scheduling which you are trying to do is am important chunk of the BIM pie. I'm sure Autodesk are working on it, I'm sure they'll want to hear how and why you are using it for construction scheduling. But I also very much doubt you'll get the API functionality to do this yourself before Autodesk have a solution in the marketplace first......

Guy