EXAMPLE:
start "Aibel AS. Iso2Ustn for MicroStation Connect Edition" /D %Appl_Root% /HIGH %app% -S%StartupFile% -WK%CurrentWorkSpace% -WW%currentWorkSet% %StartupCadFile%
I have to agree with Roald Tvedt, mvba isn't an ideal substitute for -s switch. The cons of mvba including, but not limited to:
- Non text base
- require external dependencies (com server installation etc.)
- need signing in High Security mode
- require mvba knowledge
And with the latest addition of the userpref option, we admins have to incorporate another check to ensure that userpref stay on. If I can get things done using a bunch of keyins, that would always be my 1st preference.
Tuan Le said:require external dependencies (com server installation etc.)
Which is part already part of the MicroStation installation so not really a relevant point.
Tuan Le said:need signing in High Security mode
Sucks to be a CONNECT user, I guess.
Tuan Le said:require mvba knowledge
Assuming startup script syntax is the same as standard key-ins, I would say this point is not really valid as you are only encapsulating standard key-in's in CadInputQueue.SendCommand "insert command here". Pretty straightforward for anyone to easily pick up compared to something like C++.
Tuan Le said:Non text base
For that we should be thankful. One of the things my Macro does, is check if the DGN file contains a sheet model, if it does, activate it and fit all to the view. Are you confident you can do the same with a Startup Script?
mwlong said: I was able to download a simple AutoRun.mvba
As a general point for the benefit of those who don't know already, it should be clarified that the name AutoRun is purely one of descriptive convenience and not a must-have for the Macro (my own version is named Open_Close_Design_File_Events.mvba). What is important is that it contains the relevant Module and Class code (as approximately outlined by Roald elsewhere in the thread).
Tuan Le said:And with the latest addition of the userpref option, we admins have to incorporate another check to ensure that userpref stay on.
Do you really? I've yet to hear a definitive reason why this setting is such a bad thing. Whilst I do the same role, I do find it amusing that such things are seen as a weakness in a Workspace and 'must be locked down at all costs'. After all, it's so easy for any user(with some basic knowledge) to bypass CAD Admin 'restrictions'. Predefined standards & settings are there to followed and used of course, but if users are not doing so then I would be inclined to find out why. If the effects of their actions are negative and warnings ignored, its really an issue to be escalated and dealt with by a company's management.
Tuan Le said:Yeap, last I check, there's still no proper instructions for selfsigning vba in CE from Bentley.
Have you tried any of the methods listed here?https://support.microsoft.com/en-us/office/digitally-sign-your-macro-project-956e9cc8-bbf6-4365-8bfa-98505ecd1c01#:~:text=Click%20Start,%20point%20to%20All,Click%20OK.
Tuan Le said:"Pretty straight forward for anyone" - I can see your level of expectation there Barry, but if only... There's a big difference in the amount of effort involved between modifying a txt file in notepad using standard keyins commands vs loading up MS, fire up VBA IDE, locate the modifiable key in section and have a go.
I disagree that there is a big difference, and there is also nothing stopping a user writing a macro in Notepad and then copy and pasting the code into a VBA project. With the role of CAD Manager, I'm a believer of helping others learn by demonstration; you could easily give any user the below code and tell them all they need to do take whatever standard key-in's and paste it between the quotation marks (replacing the example PLACE LINE command), and rinse & repeat for each line you would have in a script. You can then show them where that code needs to go in an AutoRun type of Macro and explain that the rest of the code should be left untouched. By then running the macro and seeing what they wrote in action, it takes away some of the supposed mystery away.
Private Sub m_OpenCloseHooks_OnDesignFileOpened(ByVal DesignFileName As String) CadInputQueue.SendCommand "PLACE LINE" End Sub
Tuan Le said:Say a simple thing, loading up a organisation task menu and setting it as root to provide a consistency across users on loading file. The extra setting breaks that consistency by default.
Again, completely disagree. Trying to set such a thing from a startup file is bad practice (IMO) and not what the file is for at all. That sort of action is for the realm of CFG files.
Hi Tim
I think both you and Tuan are assuming that a startup file is involved with the processing order of configuration variables. I'd never even heard of a startup file until recently and I note that the V8i help file and the current online CONNECT help file give next to no information on the subject. This being the case, my understanding of the purpose of the startup file comes from the link I gave in my previous reply.
Its worth noting what Inga actually wrote:
So that is its purpose in a nutshell. Its not used for assigning values to configuration variables, that is the purpose for CFG/UCF/PCF files. It therefore is only used for to automate the injection of key-ins to the key-in dialog, in the same way that a user would type them manually, and equivalent to the operations discussed previously from an AutoRun macro.
To take Tuan's example:
Tuan Le said:Say a simple thing, loading up a organisation task menu and setting it as root to provide a consistency across users on loading file.
Given that no key-in exists to allow a user to load and make active a DGNLIB within an active session, its an example of what a startup file is not to be used for.
Tim Hickman said:the point is that you are jumping back and forth between the user preference file and your startup file and saying you control things with the startup file - but these are not user preferences.
Again, its not for 'controlling things', its for setting design file settings and performing commands within a DGN file.
Tim Hickman said:Yes you can provide the startup file with your VBA but when does it issue the keyins ? how can you set the view in a file that is not open yet ?
I don't provide or use a startup file, I use a VBA Macro which issues commands when a DGN file is opened, presumably prior to when MicroStation enters its EnterIdle state.
Tim Hickman said:An example of process order might be that the user config file is needed so that the last workspace and workset can be populated in the pulldown choices or that the _USTN_CUSTOM_CONFIGURATION needs to be set before the workspace can be seen (yeah I know there is a way around this - but I am trying to make a point of the process order).
This is scenario is relevant to configuration variables during startup, which as I've explained above, is not where startup files are used.
Tim Hickman said:The user preference has nothing to do with anything you are loading in the VBA so of course none of this affects what you are doing, it affects someone trying to load things before you even get to the start page.
Well, strictly speaking, it doesn't affect me because I don't use CONNECT, plain and simple. I also don't use a startup file in V8i, why would I when it provides much less functionality that what a VBA Macro does? I also don't believe that it does do anything prior to the start page, the actions contained within it are only performed when a drawing is opened. I'm also assuming that a startup file is only run once when the first DGN file is opened and not every time a DGN file is opened, like my macro.
I'll finish by caveating that my responses above are based on what is clearly written in the AskInga article. If you believe Inga is wrong, then by all means feel free to post some alternative documentation or other proof that shows she was wrong, and that the use of a startup file is entirely different.
Barry Lothian said:Have you tried any of the methods listed here?
Sure did, even made community posts about it as well as submitted SRs for it too. Have you tried following the wiki steps yourself?
Barry Lothian said:Again, completely disagree. Trying to set such a thing from a startup file is bad practice (IMO) and not what the file is for at all. That sort of action is for the realm of CFG files.
I agree to disagree. CFG files are used to specifies which dgnlibs are accessible for a specific build. Keyin Script files are specifically to run a standard set of keyins upon application load. It seems that you have a lot of assumptions regarding how MS is best used and run by everyone, so I'll leave it at that.
Tuan Le said:Have you tried following the wiki steps yourself?
What part of me not using CONNECT do you not understand?
Tuan Le said:It seems that you have a lot of assumptions regarding how MS is best used and run by everyone, so I'll leave it at that.
I simply follow the advice as set out in official documentation authored by Bentley themselves, but I'm certainly not going to lose any sleep if someone chooses to configure their Workspace different from the recommended methods.
Barry Lothian said:I think both you and Tuan are assuming that a startup file is involved with the processing order of configuration variables.
I can't say for Tim, but your assumption about my thinking isn't correct. I believe I understand Roald Tvedt's sentiment that a config variable is a much better option compared to a user prefs. Keyin script is mostly an admin item, while the user pref puts the control into individual user territory, with UPF regularly gone corrupted (from my experience), hence my preference for a config var over user prefs. And in this particular case, a user prefs that default to off is even a worse starting point
Answer Verified By: Roald Tvedt