[quote user="Andrew Womsley"]Is it possible to convert this to a function that outputs the range?[/quote]
Not sure what you mean by that. MicroStation VBA has a number of methods that work with ranges. For example...
Sorry Jon, what i was trying to ask was is it possible for me to change the code to something like below
Function GetRefDisplayedExtents(RefName As String) as range3d ... ... end function sub MyProcess dim oRange as range3d set oRange=GetRefDisplayedExtents(default) debug.print oRange.High.X & ":" oRange.High.Y end sub
[quote user="Michal Kurzewski"]as i run three way element getting[/quote]
The standard way (I don't know your current solution) is to have three separate "start methods" that take care about slightly different ways how to access data (model, fence, selection set). It allows to write clean code, because to scan model different construction is used (can define scan criteria) than to enumerate e.g. selection set (there is no scan criteria, so tests have to be implemented). But when elements are filtered in enumeration, all methods call the same function to process note cell. And I guess to test if the cell is note cell or not the code should be split into separate methods.
[quote user="Michal Kurzewski"]i never used this before, as i had no reason.[/quote]
Read DLong type explanation in MicroStation VBA help. It's MicroStation specifc type, so it cannot be used with standard VBA functions. You should always use DLong for element id and never (!) to convert it into another type (e.g. long) if not really necessary (to display is probably the only case). And the converted result should not be treated as valid for further processing.
Because of this reason your code is invalid: Despite of it's very rare, it's not ensured that it will be possible to convert DLong to Long.
[quote user="Michal Kurzewski"]c = c + 1[/quote]
What is a meaning of that? I can guess only, but if you use c as element id to get next element, it's bad idea. If you want to move to the next element, use enumerator. You current code (if c used as element id):
Why to don't use a standard way how to work with cell content?
If oElm.Type = msdElementTypeCellHeader Then
Dim cellContentEnumerator As ElementEnumerator
Set cellContentEnumerator = oElm.AsCellElement.GetSubElements
ProcessCellContent cellContentEnumerator ' Process a cell content in your custom method
End IfIf you really need to increase DLong value (but I have to say I am really curious why), use DLongAdd method to realize DLong + 1 operation without converting DLong to smaller type.
With regards,
Jan
[quote user="Andrew Womsley"]what i was trying to ask was is it possible for me to change the code to something like below[/quote]
Yes, but not this way. Try to find some tutorial with explanation of difference between UDT (User Defined Type) and instance of classes.
Because Range3d is UDT and not class, you cannot use set oRange =, but a simple value assignment oRange = is correct. It's good to remember that if there is no New, set keyword is not used. BTW it also means the name is incorrect, because it's not object, so no "o".
Inside the function, you have to assign return value, something like GetRefDisplayedExtents = calculatedRange.
With regards,
Jan
I have a border file which caters for many sizes. This in turn is attached to designs. The users control what size border they want though the use of level display on the reference file attachment. So far so good, old fashioned and not the best but it works. Oh and for good measure the users frequently move the border placement to suit their drawing so it's not consistently in the same place.
Now here is where my problem comes in; I have to be able to add elements to the designs to make it look as though a stamp has been applied and I need to be able to determine where in the design the bottom left corner of the border is.
The bottom left corner of the border is determined by which levels have been switched on/off in the reference file display.
I have tried to use ActiveModelReference.range(True) but unfortunately this gives me the extents of the reference regardless of the level display.
I would like to be able to bring back the bottom left corner of only the displayed border.
Could anybody give me any pointers on how to achieve this?
Thanks,
Andy
[quote user="Michal Kurzewski"]its just example that collects all the IDs from model into an array[/quote]
You don't need to do that. Use ElementEnumerator.BuildArrayFromContents()
[quote user="Michal Kurzewski"]c is just an array index [/quote]
Ok, it's more clear now ;-)
[quote user="Michal Kurzewski"]its just example that collects all the IDs from model into an array.[/quote]
In my opinion you should to think about different approach, because if the model will be huge, VBA is not good at memory allocation. So it may work with some design files but not with others. I have never tried how much memory VBA is able to allocate and how fast it is.
Why you don't process elements directly as a part of enumeration?
With regards,
Jan
The .NET ScanCriteria class does not provide an element level test.
C++ and VBA scanners can both test for multiple levels.
Hi Jon,
As Artur mentions, we see the issue you provided and we are determining if this is a workflow that we can and should directly support.
In essence, the SDK developer shell configures provides our build environment with the least required configuration to do its job. e.g. set MS, MSMDE, and DEFAULT_TARGET_PROCESSOR_ARCHITECTURE, include, library, and bin directories. With that base information when you execute bmake against a valid working make file, it pulls in additional dependency search and configuration steps performed via policies and conditional make includes. For instance early in the build config environment processing if you require setting a different version of Visual Studio you can do so by defining and overriding the default value of BUILD_USING_VSxxxx (DefaultToolSet.mki). As the build environment continues to configure defaults for the default build tools AssertToolSet.mki is the workhorse that implements the "supported toolsets" for the VS version specified (or the correct defaults the SDK requires).
As you may have discovered, the Microsoft Visual Studio project file (.vcprojx) does not provide any overriding properties for: TargetFrameworkVersion or TargetFrameworkMoniker, that would instruct msbuild to use a specific toolset to compile and link project files. Since we use the SDK environment and minimal VS project solution properties in most cases having all the necessary overrides defaulted by the tools defined, we would need to investigate if we can or should support a set of changes each VS project would require to build in a minimal yet still portable "stand-alone" configuration. This would include moving make includes and library references to explicit paths and libraries to reference in each separate project, where the default locations can readily be searched and resolved and overridden safely with our current approach.
As for why you cannot directly edit the VS project properties and get the Microsoft error when doing so (and not having much time to review this deeper), I can only suspect that this post may provide some additional insight or direction as to why, or to identify the essential terminology when asking this as a msbuild type question (if needed). See: How to: Target a Version of the .NET Framework
HTH,
Bob
TIP: To obtain the most verbose build details of an application and to help understand make file configuration and processing, consider using the command line arguments: bmake +avilC YourAppName.mke > buildoutput.txt.
[quote user="Robert Hook"]As Artur mentions, we see the issue you provided and we are determining if this is a workflow that we can and should directly support[/quote]
I'm raising this point for the army of developers you hope to recruit for MicroStation CONNECT. I can see how to work around the issue, but newcomers won't have that insight. You may not like to read this, but the current development environment is clunky and hard to understand. Why do I have to run a 1970s batch file to set up the development shell? Why do I have to run another batch file to start Viz Studio? Most developers want and expect to fire up Viz Studio and skip the batch files.
[quote user="Robert Hook"]e.g. set MS, MSMDE, and DEFAULT_PLATFORM_ARCHITECTURE[/quote]
I don't see any batch, .mke or .mki file that mentions, sets or references DEFAULT_PLATFORM_ARCHITECTURE.
[quote user="Jon Summers"]I don't see any batch, .mke or .mki file that mentions, sets or references DEFAULT_PLATFORM_ARCHITECTURE.[/quote]
sorry, was rushed in response should have been: DEFAULT_TARGET_PROCESSOR_ARCHITECTURE. Correcting in original post.
C:\PROGRA~1\Bentley\MICROS~2>findstr -snip DEFAULT_TARGET_PROCESSOR_ARCHITECTURE *.bat
MicroStationDeveloperShell.bat:26:set DEFAULT_TARGET_PROCESSOR_ARCHITECTURE=x64
[quote user="Jon Summers"]I'm raising this point for the army of developers you hope to recruit for MicroStation CONNECT.[/quote]
Thank you and we certainly welcome constructive feedback. As you are aware, Bentley heavily relies on make files to build large, complex, and yes - multi-platform products to this day. You make a clear point I will bring up for review with the SDK team (again) to see if we can provide a more developer friendly VS integration options for creating and modifying MicroStation SDK specific projects in VS. We have discussed providing various basic project templates and code snip libraries to help enhance the developer experience.
Bob
[quote user="minion"]Does it look like MVBA will be supported in future versions?[/quote]
You should be able to run any existing VBA project you have developed for MicroStation V8 on MicroStation V8i SSx.
You can copy VBA source code from a V8 project to a MicroStation CONNECT VBA project. Mostly, it will run without modification. There are some exceptions that will be encountered by developers using advanced features.
[quote user="minion"]I only need it to last until 2021[/quote]
If your company only upgraded to V8i SS2 two years ago, they still have SS3 and SS4 to get through before even considering CONNECT. Could they upgrade that many times in the next five years?
Certain product (area or feature) developers may require or choose to implement new product features based on new Visual C/C++, or .NET language traits that will require newer MicroStation product dependencies to be installed on client machines and reflected in an updated product readme "Product Requirements" section.
The SDK will often internally "pre-wire" a newer toolset version and allow product developers to create and compile new code, perform testing, and eventually have it promoted into released products (with new client requirements shipped). Any upgrade issues are noted and shared with other development teams, where more areas of the product update code and build solutions accordingly. After the product has been updated to use the new toolset then the public SDK will state new requirements and set the default toolsets and 3rd party developers can to start to leverage the new features and traits of the updated toolsets in their development environments, code, and workflows.
So the product pre-requisite installs and the SDK requirements can differ for a period in time, though the SDK update requirements will specify a new toolset shortly after the whole product has been fully switched over to using the new toolset as a default.
SDK requirements should be updated more frequently than in the past in hopes developers can more quickly take advantage and realize what each significant toolset update has to offer.
HTH,
Bob
[quote user="Jon Summers"]Bentley tell us that the user customisation tools, which create a UI in a DGNLib, should be our first port of call.[/quote]
Correct
[quote user="Jon Summers"]If you look in the \MicroStation\Telerik folder, you will see a heap of DLLs in the Telerik namespace. Visit Telerik to find more about that. I think their stuff is .NET rather than C++.[/quote]
Caution. Bentley licenses Telerik controls for use within our products. We do not provide Bentley API wrappers for those controls due to our licensing agreement. Direct referencing and linking is discouraged unless a 3rd party developer has an active development license to consume and distribute Telerik controls - for their own applications.
Hi Guys and Gals,
Okay, now that I've written my Microstation VBA programs. I am wondering how long they will be able to be used. I probably should have wondered that first, but when I started in 2014 I was on V8. In 2015 they upgraded me to V8i SS2. Okay great, I only need it to last until 2021 when I retire, then it does not matter so much. I figured they only upgrade us every eight or ten years. Well now I heard they want to upgrade us to SS4 in a few months. Maybe my thoughts about how often they upgrade us are wrong. Oh and now since I've shared my programs with my colleagues and they finally tried them out, they seem to really love them. I see my programs loaded on all the workstations now! So, it would be fantastic if my programs would last beyond my time here. Does it look like MVBA will be supported in future versions? If not was there a language that would be more likely supported into future versions?
Thanks,
Minion
[quote user="EvanH"]In MicroStaton Connect we would like to use items [/quote]
Presumably, ItemTypes?
[quote user="EvanH"]When you work with tags you can choose whether they should be visible or not[/quote]
ItemTypes data (termed by some item data) are not graphical, and so is invisible until you explicitly construct a text element to display its value.
With tags, a user may inadvertently delete a visible tag element and hence damage the integrity of data in a DGN model. With ItemTypes, it doesn't matter if a user deletes the text element that displays item data.
[quote user="EvanH"]Have I missed something somewhere?[/quote]
Whether or not you have missed something is moot. The published API seems to be missing something. Here's the declaration of LabelCellHeaderHandler...
#include <LabelHandler.h>
struct LabelCellHeaderHandler : AnnotationCellHeaderHandler {}
However, I can find no mention of AnnotationCellHeaderHandler anywhere in the delivered header files. That's going to make it hard to use LabelCellHeaderHandler.