Greetings,
I continue to have a random run-time error from using a simple oElement.Rewrite function in VBA. This has worked forever in V8i and I'm not sure why this is failing in Connect Edition. Below is a code snippet. I am scanning the design file and finding any element with a feature linkage and then removing all linkages and rewriting. It fails with a random -2134324434532 whatever error and "User Aborted Function" message..which is unlikely since it's automated. Anyway, I don't understand why this is failing now. Does anyone know of peculiarities with the .rewrite function for elements in Connect?
Thanks
Sub test() 'strip elements with entity 1 linkages only Dim olink As DatabaseLink Dim olinks() As DatabaseLink Dim oenum As ElementEnumerator Dim oscan As New ElementScanCriteria Dim oelement As Element Dim I As Integer oscan.ExcludeNonGraphical Set oenum = ActiveModelReference.Scan(oscan) Do While oenum.MoveNext Set oelement = oenum.Current If oelement.HasAnyDatabaseLinks Then olinks = oenum.Current.GetDatabaseLinks For I = LBound(olinks) To UBound(olinks) If olinks(I).EntityNumber = 1 Then oelement.RemoveAllDatabaseLinks oelement.Rewrite Exit For End If Next End If Loop End Sub
Hi Scott,
please follow the best practices and to specify not only used product, but also its version (e.g. build number). Despite of MicroStation VBA is quite stable environment, specific issues were reported for particular versions.
Also, please use Insert > Insert Code tool every time you want to share a code snippet (even one line long). To read code, inserted as plain not formatted text, is exhausting.
Scott T Anderson said:It fails with a random -2134324434532 whatever error
On what line it fails? Always on oelement.Rewrite?
Exact number can help to analyze what is wrong.
Scott T Anderson said:Does anyone know of peculiarities with the .rewrite function for elements in Connect?
Not in VBA, but element update in CE is quite different than was in V8i (as plenty of other things and features).
In general, VBA is not good tool to do anything in batch. Because I do not know the context (does it run in side some bigger application, what amount of data is processed, can they be locked....), I modified the code to be a bit nicer and also added DoEvents, which allows MicroStation to empty its queue and finish waiting tasks.
Sub test() Dim oscan As New ElementScanCriteria oscan.ExcludeNonGraphical Dim oenum As ElementEnumerator Set oenum = ActiveModelReference.Scan(oscan) Do While oenum.MoveNext Dim oelement As Element Set oelement = oenum.Current If oelement.HasAnyDatabaseLinks Then olinks = oenum.Current.GetDatabaseLinks Dim I As Integer For I = LBound(olinks) To UBound(olinks) If olinks(I).EntityNumber = 1 Then oelement.RemoveAllDatabaseLinks oelement.Rewrite DoEvents Exit For End If Next End If Loop End Sub
Of course I do not know whether it is the solution, but at least the code should behave better.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Thanks Jan. This is actually running in OpenCities Map connect Edition Update 17 Version 10.17.00.156, although we've seen this in various other versions of base Microstation Connect Edition Update 18.
It always fails on the element.Rewrite function. The specific error is: Run-time error '-2147218360 (80040c48)': User aborted operation.
This is not a batch program in the traditional sense. It runs interactively on one file at a time initiated by the user. No other ops are running, file is not overly complicated. I had originally thought the variables were not being garbage-collected properly but this occurs in isolation if I use a new element object and use it first time. I don't see any changes in the documentation for element enumerator and element rewrites. So I'm surprised it's failing.. This is a vanilla installation of OpenCities Map, no customization.
Thank you.
My suggestion would be to work towards creating a completely reproducible scenario (a test case).
First, identify one File and/or File Type (dgn, dwg, ...) that will consistently fail.Second, try to identify one or more specific Element Type(s) and IDs.Lastly, though I never recommend removing linkages determine if there are specific Linkage ID(s)Knowing the variables above will better help understand what data and conditions are triggering the runtime errors. Consider Logging: DateTime, Runtime Error Number, Full File Name and Element Type, ID and LinkageID when the runtime error occurs and sharing some of the insights this may provide.
Optional: Even consider adding a loop/index counter to the information logged.
HTH,Bob
I've had issues with Mstn CE and the rewrite command. If you can replicate your error, please file a Service Request with Bentley. It would be nice to get things working correctly.
--Thanks,--Robert
It would seem the issue in this case is I did not connect to a database when starting up, therefore, because of Dynamic Feature Scoring, Micrsotation/Map could not write to the database to delete the record associated with the element. By disabling inferred DFS, I can modify the element in isolation from the DB. The error message is not indicative of this condition, I tried to isolate some elements for testing by copying them and realized that inferred DFS was causing this issue. I've noticed this in the past, just forgotten.
So I'm good for now..but I still do have random rewrite errors in straight Microstation that I have not been able to resolve. If I encounter this again I will try to document and log a service request.
Thank you everyone for your help!
Answer Verified By: Scott T Anderson
Scott T Anderson said: because of Dynamic Feature Scoring, Micrsotation/Map could not write to the database to delete the record associated with the element.
It is exactly the reason why I asked to specify used product, because an environment of products, built on top of Power Platform. like OpenMap Citties or OpenRoads Designer, have often impact to platform API.
Scott T Anderson said:If I encounter this again I will try to document and log a service request.
The random fails are often hard to catch and identify, so test data would help.
Scott T Anderson said:This is not a batch program in the traditional sense.
Anything, that is done in a cycle, is "a batch" and must be implemented carefully. Especially In VBA, when a modification is done on many elements, there are plenty of tasks MicroStation (Power Platform engine in general) have to do at background (like to process and clean input queue, update GUI etc.), but VBA code blocks all available time.