View Full Version : Mrs Peel is crashing your party.....
MikeJarosz
2007-02-21, 04:41 PM
Hi Folks!
I jumped into the Revit API pool today. James gave me a pile of code from Danny, not to mention all the other stuff lying around from Autodesk. If I could master Unix, I can do this.
My first compile of "Hello World" had 8 errors! :-(
Well at least you got it to compile ;-)
Guy
MikeJarosz
2007-02-22, 02:48 PM
Well at least you got it to compile ;-)
Guy
It ran correctly today. The problem is interesting though. I copied Danny Polkinhorn's Hello World code from AU. Typing it in, Intellisense created the "Public Function Execute()" in one very long line, so I broke it up like in the AU documentation. I wouldn't run that way. When I restored it to one long line, it worked.
So the question is: is there a continuation character ("_" in VBA)? Why would it not recognize the line when broken up?
Sorry,not familiar with VB.NET but in c# there is nothing special required to break lines.
You weren't missing a comma were you?
Guy
MikeJarosz
2007-02-22, 09:01 PM
I double checked about 15 times, but it's always a possibility. I'm not exactly new to highly formatted syntax. I worked 12 years in UNIX. UNIX and C were developed together at Bell labs.
That's the Saarinen building the new owners want to tear down.
dtownsend
2007-02-23, 11:42 AM
It ran correctly today. The problem is interesting though. I copied Danny Polkinhorn's Hello World code from AU. Typing it in, Intellisense created the "Public Function Execute()" in one very long line, so I broke it up like in the AU documentation. I wouldn't run that way. When I restored it to one long line, it worked.
So the question is: is there a continuation character ("_" in VBA)? Why would it not recognize the line when broken up?You should be able to get it to work with a "_"
Danny Polkinhorn
2007-02-26, 06:50 AM
Mike,
Download the code from here (http://forums.augi.com/showthread.php?t=55161) to compare it to yours. The underscore continuation character needs a space ahead of it, which is something I often forget. Otherwise, it should work.
MikeJarosz
2007-02-26, 02:09 PM
Next Question:
I'm digesting the AU sample code for the room area/schedules. One bit of code looks fishy to me.
Do While Iter.MoveNext()
Dim objElement As Autodesk.Revit.Element = Iter.Current
[more code here.....]
Loop
Most programming languages warn against putting statements like DIM inside loops. But VB.NET allows an initial value to be set. [Dim i as integer = 5]. What the code above seems to be doing is recreating a storage location for objElement for every iteration of the loop, then setting it to the current value of Iter. Why not just DIM objElement once outside the loop then set objElement = Iter.Current in the loop?
Some optimizing compilers actually look for this condition and correct it by putting the DIM outside the loop. Am I missing something here?
It'll save some time. However if you do some profiling you'll find the slowest task is the extraction of the current element. So only do this once per loop. In C# this is the way I do it.
object RvtObj = null;
while (Itor.MoveNext())
{
RvtObj = Itor.Current; // this is what takes the most time, only do this once per object
if (RvtObj is Autodesk.Revit.Elements.Room)
{
Room RoomElement = RvtObj as Autodesk.Revit.Elements.Room;
......
}
HTH,
Guy
Danny Polkinhorn
2007-02-27, 09:10 PM
If I were writing a super-app that I wanted to sell, I might consider such things. As is, it's cleaner because the objElement scope is limited to the Do Loop, something you couldn't do in VBA. If I use objElement outside of that loop, I might not know what it contains. The way I wrote it, I can be sure that it gets disposed of at the end of the loop and any additional calls to objElement will show an error in the editor.
My guess (cause I'm no expert) is that the CLR realizes the condition and holds the memory space as it's looping.
Hope that helps,
MikeJarosz
2007-02-27, 09:29 PM
If I were writing a super-app that I wanted to sell, I might consider such things. As is, it's cleaner because the objElement scope is limited to the Do Loop, something you couldn't do in VBA. If I use objElement outside of that loop, I might not know what it contains. The way I wrote it, I can be sure that it gets disposed of at the end of the loop and any additional calls to objElement will show an error in the editor.
My guess (cause I'm no expert) is that the CLR realizes the condition and holds the memory space as it's looping.
Hope that helps,
I started another thread on just this topic.... you confirm my suspicion that it's done for scope!
Compilers in the past would take that code out of the loop without telling the user. Maybe the pros have gotten sloppy for self-documentation purposes, knowing the compiler will clean their code up for them>
By the way, how many time zones apart are we? it's 5:30 in NY and James is setting up the NY RUGI user meeting right now!
Powered by vBulletin® Version 4.1.11 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.