API type question: Revit Journal Player - a Script Language?

[Marek Brandstatter]

Revit's journal files are pretty amazing. Think about it - they can do ANYTHING the most advanced Revit user could do! And all they are, are simple text files - issuing sets of instructions to the Revit engine.

There's a powerful language (Visual Basic) in there somewhere.

Anyone care to share? Factory? Come on guys, there shouldn't be anything to hide :)

[hand471037]

I don't think it that they want to hide anything. I saw an amazing demo this week from Ken Stowe where he was using these 'scripts' to automate and batch schedule exporting and phased animation generation. Way cool stuff.

However, I think they haven't talked about this feature of Revit much due to the fact that it seemed kinda a hack of sorts, and that it's not really that accessible to the general public. So they probably don't want people using it much, so that they can either offer something better in the future and/or not have to spend the extra time documenting it and retaining backwards compatability ala LISP when major changes are made to the product. But that's just a guess.

I'd love to see some documentation on this, so that I could start to write simular scripts, but what I would love much more is for Revit to have an 'Actions' or 'Macro' toolbar where it would record a series of moves for later playback like Photoshop or MS Office (Personally I like Photoshop's approach better, easyer to understand & change later). I think such a tool would answer many demands for an 'API' (whatever that means, seems to mean something different to every person who asks for it) while leaving it accessible enough for effective use...

[Marek Brandstatter]

I guess that's what I'm asking for - very basic documentation, example scripts etc

[irwin]

One thing to keep in mind is that there is no guarantee of compatibility of journal files from one version to the next. A journal file created in 6.0 will not necessarily run in 6.1.

[Marek Brandstatter]

Irwin - any chance of an example script or two?

[Vincent Valentijn]

We've been using journal scripts to automate processes in Revit since Revit 5.0 and it takes a few things to know and consider.

First of all it's quite simple to produce one.. open Revit, open a model, preform the actions you need, save the model and exit Revit again. This action leaves a journalfile which you can adjust, recompile, merge and so forth for your further goals. -it does take quite an analysis of the used syntaxes- if there would be more info on this it would become a more plausable tool for the non-it-pro.

replace the name of opened file with a string, replace saved file with a string.. automate string replacement in VB, make a simple selection consele and here you are.. your very own automated journalcompiler..

drop compiled journal on Revit.. and see it work without you actually doing anything!

BUT .. there's always lots of buts... it takes -lots- of things to consider beforehand. If for example you auto-output a schedule, the schedule should have the exact same name in all models you use it for [we simply added make the schedule in the journal and added a string for this name too, this helps]
Doing more than a simple replacement will almost allways make your journal go BOOM since the model info from the one in which you generate the journal and the one you execute is often not the same, which can lead to errors. Debugging such things is a very precarious undertaking, just understand that for some things journal automation will simply not work satisfactory at all.

Sorry but I cannot share the things we produce, it's part of a commercial system in which we use Revit BIM as basic tool..

[Marek Brandstatter]

Vincent - what interest me is the fact that a journal file can contain proper Visual Basic type programing code. I've have a journal file (if you want I can send it to you) with variable name declarations and conditional programming loops!

What you're seeing in recorded journal files is only the tip of the iceberg - and I'm asking the Factory to show us a bit more... So far no joy :(

[hand471037]

Marek- I don't know if what we're seeing here is Visual Basic. Others have thought it is too, and I don't know enough about it to say one way or the other, but isn't Revit written in Visual C++? Is that what we're seeing here?

[FK]

If you find you can write code in journal files and figure out what Revit puts in them, what "more" do you want? 8)

[Marek Brandstatter]

ha ha ha :lol: thanks FK that's a great answer.

I guess we could "figure" it out with a lot of research and endless trial and error. I sense reticience from the Factory. Why? Is is too early?

There's stuff we at Cadplan would like to do with Revit - mostly to do with the batch processing of family files - automatic renderings for entire folders etc. Journal scripts, I believe, will do it for us.


If you find you can write code in journal files and figure out what Revit puts in them, what "more" do you want?

"more" - how about a list of functions available?


I saw an amazing demo this week from Ken Stowe where he was using these 'scripts' to automate and batch schedule exporting and phased animation generation.

Is it possible to obtain these scripts?

[PeterJ]

Why not look at something like Girder (http://www.girder.nl) or one of the other windows automation packages, that will give you scripting control from outside Revit. I know it's not as neat but it will give you direct access to any file menu you need and the opportunity to introduce variables and conditionals...

[Vincent Valentijn]

Marek,

I think that what you think ( :?: ) is VB-like code is in fact simply the internal commandlist which is a journal-file. Only logical that it looks like VB.. There are things in there that seem to declare vars and conditional loops for sure..
but it's got nothing to do with a real API, it's simply how the software does 'it's thing' and without true API you cannot use it in your own way simply because it is not clear [from this output] -what- is actually happening. You can invest time to unravel stuff but I don't think it's worth the effort and there is no guarantee to any workable method as an outcome.
All you can do is recognise all the limitations, only analyse journals as far as your needs go, accept them and work with the strings you can actually pull :) and make an official request for an API at Autodesk Revit, at least.. I suppose you need to be ADN member to do such things? Else you might want to contact some people [Marty Rozmanith is involved in API] to make your wishes known? The more people make requests, the better the chances of these things becoming available soon I'd think :!:
In official papers from about.. euh.. I guess around the time Revit got bought by Adesk, they stated that API was supposed to come a.s.a.p. Instead, what is happening now, they only add some simplistic parameter controls, leaving what we consider to be 'real' customizablility untouched.

Don't worry though, there is plenty you can do with the present version of Revit. :D

[Marek Brandstatter]

Marek- I don't know if what we're seeing here is Visual Basic.


I think that what you think is VB-like code is in fact simply the internal commandlist

Jeffrey, Vincent - What we're seeing is a form of VB Script - a scaled down version of Visual Basic. I'm pretty certain that it's the beginning of a Revit API :)

FYI - VB Script provides four forms of looping statements:

For..Next
For Each..Next
Do..Loop
While..Wend

Some VB Script links:
http://www.intranetjournal.com/corner/wrox/progref/vbt/ch21_20.shtml
http://www.intranetjournal.com/corner/aitken/vbs-1.shtml

Of course, bear in mind that VBScript for Revit may be different to Web based stuff.

But its a good place to start preparing for what's coming.

[hand471037]

I'm pretty certain that it's the beginning of a Revit API

Journal files have been in Revit since I've been using it. So I don't know how much a 'begining' it is... ;)

[Marek Brandstatter]

I believe the VB scripting ability is fairly recent, hence Ken Stowe's "batch schedule exporting" and "phased animation generation" routines.

Essentially one can now automate various *batch* command sequences using IF... THEN type statements for example. This type of intelligence can only be implemented via hand coding.

I'm simply curious to what degree the VBscript in Revit is currently implemented. For example - are there any DATA RETRIEVAL functions? If yes, then we effectively have an API.

But guys, judging from the muted Factory response, I can only assume that "intelligent journals" are not yet ready for mass consumption :(

[Vincent Valentijn]

Marek,

In your example you refer to conditionals as being VB-like.. in fact even Pascal and other ancient programming environments use and cannot exist without conditionals. I don't know if knowing about conditionals would be enough to actually get to know true syntax, for API to be fully programmable [even by our experts] it would need some sort of debugger, a way to define and call your own functions and alow a direct way into Revit instead of generating some script for Revit to execute.

I think you should see Journal.file capability more in the lines of VisualLisp.. and as said before a big -/- is the lack of ability to even get the 'drag the journal to Revit.exe' out of the equation.

We've been down the path of trying to implement some functionality of our own, had conversations with lots of people within Revit, also directly with Development... but to no avail. Hope you're more lucky :wink:

[FK]

Sigh...

Journals are an internal testing and debugging tool. Their purpose is to reproduce user actions. They can batch some dialogs, but they cannot support serious Revit extensions. They are not an end-user tool. You say "give us a list of available commands", we hear "commit time to compile and continuously update the list for a tool that won't make the users happy anyway."

In due time, Revit will become an extensible platform, it's unavoidable (i.e., I'm stating my expectation here, not making promises on behalf of the company :) ). There's just no ETA yet...

[Marek Brandstatter]

Thank you very much FK. Probably the best explanation so far on this thread.

Now indulge me while I induce one final round of eye-rolling at the Factory :roll:


You say "give us a list of available commands", we hear "commit time to compile and continuously update the list for a tool that won't make the users happy anyway."


Now... if say this list - which you guys must already have in rough form lying around somewhere - took some openhearted indivdual say 20 min to put in a text file and post here - with the clear understanding that...
(1) USE AT OWN RISK!!! (2) Dont expect any support (3) Otherwise Enjoy!

You may say Im a dreamer, but Im not the only one.

[beegee]

You may say Im a dreamer, but Im not the only one.

Imagine there's an API
It's easy if you try
No journal files to thwart us
No C+++ to make us cry
Imagine all the Revit people
Living for today...

[Marek Brandstatter]

All together now...

[gregcashen]

Thank you very much FK. Probably the best explanation so far on this thread.

Now indulge me while I induce one final round of eye-rolling at the Factory :roll:


You say "give us a list of available commands", we hear "commit time to compile and continuously update the list for a tool that won't make the users happy anyway."


Now... if say this list - which you guys must already have in rough form lying around somewhere - took some openhearted indivdual say 20 min to put in a text file and post here - with the clear understanding that...
(1) USE AT OWN RISK!!! (2) Dont expect any support (3) Otherwise Enjoy!

You may say Im a dreamer, but Im not the only one.

Unfortunately, I think the main point that this is an internal debugging tool is being missed. It's akin to saying that they should just give us the source so we can add our own tweaks as needed. It's not gonna happen, nor should it. At least not in this way. I think it is clear that an API will be forthcoming in some future release. Those who are dedicated to joining the ADN will surely get the chance to make all the cool tools they want when the time comes, but if this is indeed not a tool designed for the end user, then it should be up to the end user to try to figure it out rather than have the factory have to duplicate ANY time supporting it. I just see way too many people latching onto the notion of an API without giving thought to the tremendous amount of additional support required to back it up.