For Microstation V8i, I have been given the assignment of converting several UCMs to Basic or Visual Basic. Since there is a manual for converting UCM to Basic, I decided that I would convert them to Basic. Then new macros could be created in VBA. I am just learning Microstation and of course, my management wants this assignment completed quickly.
I would like to know if it is possible to call a Basic Macro from another Basic Macro with parameters of any built-in or Macrostation type, such as an MbePoint. If not, is there an alternative? These small UCM Macros that are called frequently by many Macros, but I don't think there are include files in Basic.
For now, I'm using Basic Subroutines, which isn't ideal.
I would like to convert the UCMs to VBA, but I think that would take much longer, unfortunately.
Recommendations …
Regards, Jon Summers LA Solutions
I highly recommend that you convert things to VBA over Basic. I have never tried this so I do not know how successful it will be, start the VBA recorder and then run the UCM it should record the playback of the UCM depending on how complex, it may help you get what you need.
Could you provide a sample UCM? That might help with suggestions and ideas of things to do to help you achieve what you have been asked.
BTW, to add to the suggestions of going straight to VBA, although you may not be familiar with it, it will likely be the fastest way to accomplish what you are looking to do. Further, subsequent maintenance of the customizations will be MUCH easier than dealing with something that is "converted" from one "language" to another and then "converted" to another. I speak from experience there.
This is not meant to insult, it is merely to provide perspective (from someone who has "been there"...)
From the MicroStation FAQ.
Question: Will MicroStation BASIC macros work in MicroStation V8i (SELECTseries 3)?
Answer: MicroStation BASIC is supported in MicroStation V8i. However, MicroStation BASIC has not been enhanced and is likely to be unsupported in future versions. Bentley recommends migrating existing MicroStation BASIC code to Visual Basic or Visual Basic for Applications.
Elaine, the process you are describing is what I consider to be a typical "Migration Project". There are several options and considerations in the process that should be evaluated before being able to project how long your migration project will take.
Here are some considerations:
How has the Product changed? In your case MicroStation SE (5.7) to MicroStation V8i 8.11 has change drastically in capabiities and workflows. These points are fundamental in your approach.
MicroStation V7 had 63 levels and the V7 design file format. MicroStation V8 has a new format, capabilities, workflows, and nearly limitless levels, models, styles (line, text, dimension), etc. For one, your UCM unless the most simple will not work in MicroStation V8. MicroStation BASIC being older also has the similar limitations and both would require several and/or extreme hacks to accomplish something that a more modern MicroStation VBA could handle with ease. MicroStation VBA has its (smaller) set of limitations, but can be augmented with MicroStation MDL (C/C++ programming language APIs) to enhance VBA, or offer functionality in a stand-alone manner.
The first part of such a daunting task is to ask some of these questions from the CAD admin/operators:
1. How many programs are there?
2. What do they do?
3. Does the Product NOW offer this functionality?
4. Have the workflows in the product changed making the older way ineffecient or obsolete?
5. How many programs do we need to migrate?
6. Do we only need to migrate some or all the code/featurs of the customization forward?
7. What programming language(s) are required?
8. Do I have the experience necessary to perform some or all the work defined as being required?
9. Can I meet the projected deadlines?
10. Will I have adequate time to test each app, feature, and (new) workflow and validate everthing is working?
There are more considerations along the way, but these steps above are generic and apply to any software product that provides customization/programming options.
I would recommend to evaluate the existing functionality and find it, or find out how to accomplish it in the new product. Use MicroStation VBA since it is relatively easy to learn and prototype functionality quickly. TIP: Plenty of sample code in the VBA Help document - Alt F11, F2 (object browser), Search for something - e.g. Cell, then hilite an item displayed in the results and Press F1 - noting "Example" hyperlinks for sample code. Lastly, if the deadline(s) are imperative I would recomend that you consider contacting our Bentley Profession Services group since they are already fully equipped to handle and meet your customization needs. Here is some contact information for convenience.
Bentley Professional Services (BPS) - For Bentley product customization services
Web: www.bentley.com/.../Bentley+Professional+Services
E-mail: bentley.consulting@bentley.com
Wish you the best in your efforts and please make sure to use the Be Communities to help you find your way and help with any specific programming questions you may have.
HTH,
Bob
Thanks, Jon. Then if Microstation BASIC does not support all the features of Microstation (of any version?), does that mean that UCMs can't be completely converted to Microstation BASIC?
Unknown said:That mean that UCMs can't be completely converted to Microstation BASIC?
Keep in mind that UCMs support even fewer features of MicroStation V8. BASIC provides more than UCMs, and VBA provides more still and is not obsolescent.
For example, consider levels. In V8, levels are named (in MicroStation SE they are numbered). There is no restriction on the number of levels (in SE, there are 63). VBA can handle an arbitrary number of named levels; BASIC can't, UCMs can't.
But that introduces another question: What will your organisation do with an unlimited number of named levels? Will they change their way of working (everyone who moved to V8 successfully embraced that change)? If levels influences their way of working, should the UCM functionality also accommodate those changes?
no one here can help you if you don't supply the UCM's to examine......period.
I was unable to find ucm2basic.ma. I looked in the directory where the ma files are for the older version of Microstation. Awhile ago I had read online that there was a bat file called ucm2basic that Bentley could provide and I called them. But they told me that this was no longer available.
I recently found my copy of the MicroStation Productivity book. It lists many of the register and/or tcb variables that UCM's used. If you need any explanation of some of these to determine what the code was doing, I can help.
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration
Thank you, caddcop. I've been using "Microstation-UCM-REF15.pdf" and "UCM-to-Basic.pdf" to understand the UCM code, but I don't have the "MicroStation Productivity book." What I'm not clear about is CVT:
CVT A0 = '.25'
CVT A1 = '.625'
CVT A2 = '.5'
CVT A3 = '.125'
When I used the counterpart of this using Basic, the graphic didn't work correctly. But when I ignored it, it did. I converted the UCM code to VBA ignoring CVT and it also works.
Is there something different about the MIcrostation 8vi version compared to the older version the illustrators are using, Microstation SE O5.07.01.22, so that I don't need to translate CVT to the VBA counterpart?
Unknown said:CVT A0 = '.25' Is there something different about the MIcroStation V8i version compared to the older version so that I don't need to translate CVT to the VBA counterpart?
Is there something different about the MIcroStation V8i version compared to the older version so that I don't need to translate CVT to the VBA counterpart?
There's a lot different. CVT is a conversion instruction: the quoted string is converted to a decimal and stored in register A0.
VBA has more explicit assignments:
Dim decimalNumber As DoubledecimalNumber = 1.234
The TCB registers Ax are globally-available storage slots. Those UCM slots don't know or care what's stored in them: an integer number, floating point number, or a 3D point. A VBA variable is local to your macro, and is usally declared to store a certain type of data. That makes VBA much safer to use.
In "UCM-to-Basic.pdf" it says that CVT converts between working units and UORs and stores the result in var1. If var1 is a character string, the conversion is from UORs (Units of Resolution) to working units and then I would need to find the equivalent in VBA.
However, in VBA I did do something similar to what you showed in your reply, except made them const. So I don't need to be concerned about working units and UORs in converting CVT?
MicroStation VBA's default transform works in master unit values and UORs conversions should be minimized except where absolutely required by a method.
The MicroStation objects (Attachement and ModelReference) provide the following convenience functions:
Here is a sample showing how to take those numeric values and display them as strings, note that you can use Microsoft VBA's CStr() function to convert a number to a string value if you need to store the result:
Sub ActiveModelDisplayWorkingUnits() Debug.Print "UORsPerMasterUnit: " & ActiveModelReference.UORsPerMasterUnit Debug.Print "UORsPerSubUnit: " & ActiveModelReference.UORsPerSubUnit Debug.Print "UORsPerStorageUnit: " & ActiveModelReference.UORsPerStorageUnitEnd Sub
Lastly as many have mentioned already, MicroStation BASIC, MicroStation User Commands (UCMs), and MicroCSL have all been deprecated prior to the MicroStation 8.1 version release and documented in some of the following references:
HTH,Bob
Unknown said:I don't need to be concerned about working units and UORs in converting CVT?
VBA provides the Point3d and Point2d data types for working with coordinates. Normally, you work in Master Units, and don't need to be concerned about UORs. Because UCMs used UORs you often had to convert between the two. You can assign a Point3d the like this...
Dim point As Point3dpoint.X = 1.point.Y = 2.point.Z = 3.
Or, you might prefer the API, which offers useful methods like this...
Dim point As Point3dpoint = Point3dFromXYZ (1., 2., 3.)
Hi Elaine,
Another suggestion... UCM is a programming language with a bunch of very simple tools that can't do much. I was helping someone convert some UCMs to VBA. First, he had tried to do automated conversions to BASIC, which produced unreadable, terrible code which was a major pain to work with. Another thing I saw was these huge drawn out processes to do something very simple. In UCM, to get the square root of "A" squared plus "B" squared, it was a 4 or 5 step process, rather than one line of code. Also, point manipulation was done on X, then Y, then Z. In VBA, that could be one command, and it definitely should be one Point3d variable rather than three un-named variables.
What I'm trying to say is that it is good to take a step back and see what your UCM code is doing. Then translate the concepts to VBA--not just a direct word-for-word conversion.
--Robert
Unknown said:It is good to take a step back and see what your UCM code is doing. Then translate the concepts to VBA.
Excellent suggestion!
Unknown said: It is good to take a step back and see what your UCM code is doing. Then translate the concepts to VBA. Excellent suggestion! [/quote] I'll second Robert's suggestion. I've converted over 300 UCM's to VBA's for different clients. That is the exact approach I took, replace the functionality but redesign from scratch. You are needlessly making the job much more difficult if you are examining every line of UCM code to translate to VBA.
It is good to take a step back and see what your UCM code is doing. Then translate the concepts to VBA.
[/quote]
I'll second Robert's suggestion. I've converted over 300 UCM's to VBA's for different clients. That is the exact approach I took, replace the functionality but redesign from scratch. You are needlessly making the job much more difficult if you are examining every line of UCM code to translate to VBA.
Rod WingSenior Systems Analyst