Hey all. I've run into a problem and I hope someone here can help me. I've got a macro written that places a cell and then automatically sets the tags. However, when I call CreateCellElement2(), I'm getting a run-time error with code -2147218383 (80040c31) and text "No such application".I searched online for that particular text, and sure enough, the first result was right here on this forum, from a few years back. But the person who made that posting never got an answer, they just settled for using key-ins. In my case, this process is designed to run multiple times, so key-ins aren't very attractive. Below is the code where I'm getting the error. For the record: ZP() is just an alias for Point3dZero. I've verified that the cellName var gets the correct cell name, that the correct cell library is attached, etc, etc.
'select which block
Dim cellName As String
cellName = Left(vp.cellName, Len(vp.cellName) - 3)
'set up and create the cell
Dim cellBlock As CellElement
Set cellBlock = CreateCellElement2(cellName, ZP(), Point3dOne(), True, Matrix3dIdentity())
'might need to specify the sheet name with activedesignfile.models(sheet name)
to understand your situation better I have a few questions:
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
I made very simple test and my works fine:
Dim cellEl As CellElement
Set cellEl = CreateCellElement2("simple shape", Point3dZero(), Point3dOne(), False, Matrix3dIdentity())
Can you share your cell library?
Darin Rodberg said: if I do not call .Redraw, any element I create or modify using VBA does not appear or update on the screen.
It's not true. From MicroStation XM Edition, MicroStation itself takes care about redrawing model content when it changes. This change is a consequence of migration MicroStation to DirectX (and addin transparency, priority etc.) that happened in XM Edition. From this time, I guess the only place where .Redraw is required is dynamics, e.g. when implementing primitive or locate command, in general when element existing in memory only has to be displayed.
For example, this simple code works perfectly from XM Edition, the added shape is displayed immediately without .Redraw is used.
Dim points(3) As Point3d
points(1) = Point3dZero()
points(2) = Point3dFromXY(10, 0)
points(3) = Point3dFromXY(5, 10)
Dim shape As ShapeElement
Set shape = CreateShapeElement1(Nothing, points, msdFillModeNotFilled)
The same is for element modification, no redraw is required:
Dim shape As ShapeElement
Set shape = ActiveModelReference.GetElementByID(DLongFromLong(511))
shape.Color = 3
If your code behaves in a different way, something is probably not correct with your VBA (not current MicroStation DGN 8.9 Object Library is referenced, registry mismatch in VBA engine registration?), as I don't recall any setting in MicroStation (but maybe there is some) that can delay the display and requires elements to be redrawn explicitely.
Darin Rodberg said:I have several resources, including "Learning MicroStation VBA", "MicroStation VBA Essentials" and "MicroStation VBA for Advanced Users", all of which indicate that you must call .Redraw...
They all are obsolete, because they were probably written for MicroStation V8 2004 Edition or older versions.
Darin Rodberg said:Also, I have found that calling .Rewrite often helps with a frequent issue I've experienced in which random lines of VBA will be skipped at run-time in more complex scripts.
I have never heard about such VBA issue and I don't recall it has been discussed in this forum. VBA is not the best tool, but if the code is well written and properly structured, it works fine ... which I agree can be sometimes quite complex task and may require deeper knowledge how interaction between VBA engine and host application works. In my opinion if the code does not work correctly, the only right solution is to debug the code and trace where the problem is, not to add just another line of code.
Darin Rodberg said:This is an issue with VBA in general, not Microstation as it occurs in almost every application that includes the VBA IDE
This statement surprised me a lot, so I tried to find some references or discussions. I found some (not too manyú, but all of them were solved and identified as a problem of wrong code (not used DoEvents, misunderstanding how modal / non-modal forms work, strangely allocated objects and memory...), not as VBA feature.
It's not true. From MicroStation XM Edition, MicroStation itself takes care about redrawing model content when it changes.
It is true: I speak from experience, and that experience is consistent. If I do not call .Redraw after calling the .AddElement method, or after modifying an element using code, it will not appear/update. This is also documented in the help file, in every single example that creates or modifies an element.
If your code behaves in a different way, something is probably not correct with your VBA (not current MicroStation DGN 8.9 Object Library is referenced, registry mismatch in VBA engine registration?)
The installation is current by every metric Bentley permits me to check by, unless there are metrics I am unaware of (which would not be particularly surprising, given how stingy Bentley seems to be with documentation).
The latter two both specify that they were written for SS2 and are applicable to SS3, and the first was published in 2006 and does not specify a version, so this may be applicable. However, as I previously indicated, the help files included with the installation of SS3 all show the .Redraw method being called in every example, and this exactly matches with my experience.
I have never heard about such VBA issue and I don't recall it has been discussed in this forum. VBA is not the best tool, but if the code is well written and properly structured, it works fine ......This statement surprised me a lot, so I tried to find some references or discussions. I found some (not too manyú, but all of them were solved and identified as a problem of wrong code (not used DoEvents, misunderstanding how modal / non-modal forms work, strangely allocated objects and memory...), not as VBA feature.
Okay, first let me give you some background: I have been developing in VBA for over a decade, I have also done web development using JQuery/HTML/CSS, PHP and ASP, desktop development using C#, Common LISP, C++, Java, etc, etc, and integrated chip development using C... All of the usual suspects. I am telling you this not because I feel particularly defensive about it (I am "brand new" to developing for MS after all, and I know exactly how lost a seasoned developer can be when using a new API or new libraries or resources). But I do know how to write well-structured code, and debug it. There may, indeed, be errors in my code, but I am quite confident that such errors would be errors in interfacing with MS. I am not permitted under my work contract to publish the full code, else I would be happy (ecstatic, really) to have an MS VBA expert go over it in its entirety.
When I said this was an issue with VBA, I didn't mean to suggest that it is exclusive to VBA. This is a very common problem with any interpreted language running on modern operating systems, particularly Windows, and particularly when running in tandem with multiple, high-memory-usage applications, such as ArcGIS and MicroStation (which is the case with every machine this script is intended to run on). I have experienced this exact issue with C# scripts in Notepad++, with EMACS LISP scripts in EMACS, and even with batch commands running in powershell (though the latter can be mitigated to a great extent with properly set permissions), not to mention every single VBA application I have used or written (including those I have downloaded from Jon Summers' site, whom I feel we can both agree is writing well-formed code). It is a well-known issue with interpreters, and goes back to the earliest days of automatic garbage collection and interpreted languages. I am unable to post links (not sure why, because I could do it the last time I posted), but there are a number of scholarly papers on the subject, including Non-determinism in Functional Languages by H. Sondergaard and P. Sestoft, Mind Your Language(s): A Discussion about Languages and Security by Eric Jaeger and Olivier Levillain and more recently, Quantifying the Performanceof Garbage Collection vs. Explicit Memory Management by Matthew Hertz and Emery D. Berger. All of them address the issue to varying levels, and I know there are other papers which address it more directly, though I cannot recall them at the moment. Interpreted development forums often contain entire novels worth of developers complaining about it. Try searching for "VBA garbage cleanup" and "interpreted language garbage cleanup" to find more information.
A more general explanation would be to analogize it to a sort of accidental code injection attack: the VBA interpreter occasionally ignores the allocation of memory to other applications when such allocations are made and released quickly and overlap with memory the VBA application expects to be free (which happens due to the high overhead and subsequent slow processing of interpreted languages). This causes the interpreter to read memory addresses which contain data from other applications as if they contained data placed there by VBA, generating low-level exceptions which are often handled by the OS by simply moving to the next specified memory address.
The extensions I am writing would, I know, be best written as an add-on to Microstation, developed in C#. However, Bentley has essentially ignored over four months of queries by myself and my employer into acquiring the SDK's which are included in our SS subscription (I am dead serious: our interactions with them have been the stuff of customer-service nightmares), and the need for these extensions is such that I am unable to wait until they finally get around to giving us a straight answer.
Returning to the subject at hand, the problem I am experiencing seems to be identical to the one experienced by the user who posted the question "Problem with CreateSharedCellElement2 Method". I have implemented his solution in the meantime (using key-ins) but as this slows the processing down, I would be very interested in hearing from anyone else who has encountered this problem.
Darin Rodberg said:It is true: I speak from experience, and that experience is consistent.
Because what you described is completely different that what I know from XM Edition release time, I produced a short video:
Until my and your MicroStation installations behave differently, it's hard to discuss the rest of the code, because it can be affected by this issue also.
Because it seems web player does not managed the video correctly, I attached is as zip file.
Darin Rodberg said:When I call CreateCellElement2(), I'm getting a run-time error
Darin Rodberg said:Perhaps I am using an out-of-date library (and out-of-date documentation)
What does VBA help tell you about, for example...
Regards, Jon Summers LA Solutions
Darin Rodberg said:I am unable to determine how to even go about updating my dll's
I guess the first step is to check what is referenced to MicroStation VBA project in VBA Editor:
MicroStation V8i versions have to reference Bentley MicroStation DGN 8.9 Object Library, I recommend also to check if its path is correct.
I am not sure if there is some other simple test that can be done.
You can try to download Bentley Prerequisities installation and to run it, because it will check and re-register everything related to MicroStation VBA. I took the link from this discussion.