by Mark Stefanchuk, cadmanage.com
I’m not really a big fan of increasing the number of MicroStation config variables. Where possible, try to use built in variables. For example, you can use CreateCellElement3
with just the name of the cell as long as the cell library is defined in MS_CELLLIST. You might have something that looks like this in your VB code.
oCell = MainForm.oMSApp.CreateCellElement3(MainForm.uc_o.txtCameraName.Text, Point, True)
This is from a VB.Net example, that’s why the MicroStation Application object is included.
Here’s how I might define MS_CELLLIST for use with photogeoDGN.
CADMANAGE = C:/ProgramData/Cadmanage/PhotogeoDGN/Contents/ MS_ADDINPATH < $(CADMANAGE)Windows/8.11/ MS_CELLLIST < $(CADMANAGE)Resources/*.cel
Sometimes however, it is necessary to identify a special folder or some other resource in your custom program. For example, your program might include a catalog file that provides some engineering data that your program will associate with a cell. You could decide to put this in a resources folder that is always in the install directory. But, a better solution might be to let the end user decide where she wants to save the resource. In this case the resource or file is one that MicroStation doesn’t know anything about, but your program has to be able to find. To fix that we could define the following,
CMRI_CATALOG = $(CADMANAGE)Resources/testcatalog.xml
Put the variable in one of MicroStation’s configuration files, like your UCF. Now, to access the variable from your custom VBA program you need to use ConfigurationVariableValue. Here’s how to do that in VBA.
The example will print the value of the configuration variable in the VBA IDE’s immediate window.
Use this expansion to open the file, or in this case define your XML document object.
As long as the variable name is different than any other MicroStation config variable, you can use it, but I would recommend including a prefix. In the previous example, I used CMRI (for CAD Management Resources, Inc). This just helps to avoid variable conflicts.
by Lorrie Mattor, CADmanage.com
Do you prefer keying in a few shortcuts over clicking on menu items? Then CADpilot’s Key-In functionality is just for you!
The CADpilot key-in window is used primarily to issue menu and button shortcuts but may also be used to issue MicroStation commands.
To bring up the key-in window, select the “\” (backslash) key.
Type the command shortcut into the Textbox and then select the Enter button.
CADpilot menu or button shortcuts require the “\” (backslash)
Standard MicroStation commands are executed without the “\” (backslash).
Lorrie is a Technical Consultant for CADmanage.com specializing in CADpilot integration, system’s analysis, technical writing and data manipulation.
by Mark Stefanchuk, CADmanage.com
I was thinking about all of the things a CAD Manager does and decided to start a list. It was very long. At the highest level the list is typically support, training, and development – a very basic IT management framework. That is, get feedback from support and address systemic issues first with training and if necessary with development. Of course, the details of the day to day activities of a CAD Manager paint a much more complex picture. The CAD Manager doesn’t just have to know how to reset passwords. The CAD Manager also has to be able to peel back the layers of the CAD system one by one to separate the relevant from the irrelevant. CAD support might appear to be as simple as demonstrating feature function, but more often it requires traversing multiple integrated systems.
A few years back I had a situation where several users were seeing really poor performance, but only when working in a CAD drawing. Basic drawing commands – lines, circles, boxes and text were really slow. Everyone had the same software, the same computer, the same OS, but only a handful of users were seeing performance degradation. What gives?
In large corporations there are large IT teams and on occasion they can be a challenge to work with. Their requests can seem ridiculous at times, but usually these requests or “push-backs” are opportunities to eliminate a suspected root cause. In this case, our IT partners were skeptical and told us that we were imagining the performance issue. Ok. A simple timing script resolved that. I created a macro to place objects into a drawing. Pretty simple really – time stamp before and after and take the difference between the two. In VBA use the timer function. The output will be in seconds.
Dim t1 as Single, t2 as Single t1 = Timer() ‘ do lots of stuff ‘ ... t2 = Timer() Debug.Print Str(t2-t1)
Test some stuff, but be sure that your macro tests remote resources not just local desktop operations. Open a file, or place a block (or cell) that resides on a server. If you want to run a file open test, run it from a VBS.
' VBS - open and close a MicroStation Files dim t1, t2, msApp t1 = Timer() Set msApp = CreateObject("MicroStation.Application") msApp.visible = 1 msApp.mbeSendCommand ("rd=C:\tmp\test.dgn") msApp.quit t2=Timer() '--- CREATE AN OUTPUT FILE SO THAT WE KNOW IT IS EMPTY Set tfo = CreateObject("Scripting.FileSystemObject") Set tf = tfo.CreateTextFile("c:\tmp\tout.txt", True) tf.WriteLine(" TIME FOR FILE OPEN AND CLOSE: ") tf.WriteLine(t2-t1) tf.close
The test did the job. We were able to prove that performance was bad on these select machines. Still no root cause, but we proved the problem existed. The next “push-back” – well it must be the CAD software. Hmm. I thought I had done enough, but I went ahead and stepped through my checklist (working inside out) – drawings same problem with a new/different drawings so it can’t be drawing file specific, data connections not applicable, CAD application versions and settings are the same, CAD engine configurations the same. There weren’t any differences related to the CAD environment.
Volley back to IT. At this point I had the evidence to demonstrate that the problem wasn’t due to the CAD environment. This meant that our IT partners now had to take a closer look at the differences in the desktop programs and utilities that they managed. This included many things including network, terminal windows, OS system and patches. Network diagnostics checked out, OS system and patches ok, anti-virus software was the same, but… there was a difference. Turns out the AVS settings were not the same. On the computers with the problem the check box to scan remote computers was checked. Every time the CAD program grabbed a file or resource from the server it was being scanned.
A systematic analysis of each component of our design automation platform eventually found the root cause. And, in this case the resolution was relatively simple. That is, turn off remote detection. No need for redundant scans of internally managed servers.