Journal file DBG_WARN

[valamar2005-site]

Hi all,
I have this two warnings within the journal file.. BUGS???
DBG_WARN: Paul now requests that you keep data dictionary entries sorted by increasing offset.: line 599 of Archive\DataDict.cpp.
"DBG_WARN: Revit has allocated far more than the expected number of GDI resources -- check for leaks.: line 3405 of MFC\CRS.cpp."

One more question...
Journal files are dedicated to debugging, aren't they? Can't we script also?

Sorry for that (perhaps) silly questions but I am only a beginner!

[FK]

These warnings talk about efficiency, so you can ignore them.

You can script if you like, as long as you don't expect any support and are OK with any release or build breaking your scripts.

[James.Lupton]

We have used the journal files to control repetitive processes such as exporting views for a construction sequence

For example

to export a sequence of images controlled by switching on each phase in turn.
to export a group of AVI files each of which represents a fly through of part of a model with certain phases switched on.
to export 3D dwg files representing each phase of the proposed construction (this is normally used for export to NavisWorks)
Updating previous version families to the latest version.

Basically anything that is repetitive can be scripted with the journal file.

Most of the journal file is output information which is not needed and when you get to grips with it you can cut the file down to a few simple commands.

What I would like to do is to be able to run the same scripts as we can using the journal file from an external command through the API.

I am not sure if this is possible yet.

[GuyR]

What I would like to do is to be able to run the same scripts as we can using the journal file from an external command through the API.

I'd rather see this functionality exposed via the API A lot cleaner than using journal files and potentially a lot more powerful.

One for the wishlist.

Guy

[James.Lupton]

Guy I have been asking for this since V3 but so far it has been of no use. My requests keep falling on deaf ears.

Have you any ideas on how to get this point across.

We first used the journal files to upgrade V3 in house families to V4.

The fact that the journal file records is great since this helps to figure out what the script should do.

Keep the write to journal file but give us the ability to run the scripts from a command line now that would be great.

So how do we drum up support for this

[GuyR]

So how do we drum up support for this

I would imagine (hope) the people who need to know are reading these forums.

The problem is, it's a fine line between exposing the whole API and ending up with the mess that is AutoCAD or not exposing enough to make the API useful. My understanding is the factory are taking a cautious approach to exposing the API and I 120% agree with this approach.

For example some of the things you are doing with the journal files would be useful functionality from within Revit. And certainly with batch rendering issues along with all rendering issues it confirms what most of us already know. That rendering in Revit needs a major overall. We all know Revit MEP is coming next year, why can't they provide similar information on rendering? Anyway to get back on track....

One of the advantages of pyRevit is you'll be able to script some quite powerful functionality easily. I'm hoping this will highlight areas where more API functionality would be useful. As part of this I'll also be able to assemble more of a wish list.

With some of my examples I'm writing I'm already coming across examples where I think "this should be coming from the factory". And there lies the problem with an API. The reason Revit is so clean is because there hasn't been an API for people to bastardise Revit. And that is the worst thing that could happen to Revit.

I'm sure the Factory is listening but with a company the size of Autodesk the only way you'll get some serious action is if for example you purchase >200 Revit seats or come from firms with the initials SOM or the british equivalent.

If you are really serious about the API then at the very least the ADN subscription is probably a good start.

HTH,

Guy

[beegee]

>>If you are really serious about the API then at the very least the ADN subscription is probably a good start.
>>
Got a spare US$ 25,000 pa. ? Get ADN Premier Partner - it rocks !

ADN Premier Partner : Service level for software development teams embarking on major new software development activities

[GuyR]

I thought ADN was only about $1500US for membership?

Does the $25000 include free entry to AU ;-)

Guy

[beegee]

I think ADN Standard - 1 User is US$1200. per calendar year , January 1 to December 31 - and not prorated. ( That definitely doesn't include entry to AU though. :) )




I thought ADN was only about $1500US for membership?

Does the $25000 include free entry to AU ;-)

Guy