I have a VBA macro that prints the current DGN on several pages.
We design various rectangles on a specific level with a specific cell name. The print style specifies that the contents of each of these rectangles ends up on a separate page. The print style is defined in a .dgnlib that is loaded by means of the MS_DGNLIBLIST_PRINTING configuration variable.
So far so good.
The macro is composed as follows:
ActiveDesignFile.Views(<myView>).ShowLevel <myLevel>CadInputQueue.SendKeyin "filedesign"ActiveDesignFile.SaveCadInputQueue.SendKeyin "MDL LOAD bentley.printorganizer.dll"CadInputQueue.SendKeyin "PRINTORGANIZER NEW"CadInputQueue.SendKeyin "PRINTORGANIZER PRINTERDRIVER pdf.pltcfg"CadInputQueue.SendKeyin "PRINTORGANIZER ADD ACTIVEFILE " & <myStyleName>CadInputQueue.SendKeyin "PRINTORGANIZER PRINTDESTINATION " & <myPdfName>CadInputQueue.SendKeyin "PRINTORGANIZER SUBMITAS SINGLE"CadInputQueue.SendKeyin "PRINTORGANIZER PRINT ALL"CadInputQueue.SendKeyin "PRINTORGANIZER DELETE ALL"
The problem is that MicroStation reports error "Unable to load design file <myDgnName>" when executing the line CadInputQueue.SendKeyin "PRINTORGANIZER ADD ACTIVEFILE " & <myStyleName>.
It takes 10 to 20 seconds to run this statement.
The funny thing is that everything goes well if the very same statement is executed twice in a row. Even when I put CadInputQueue.SendKeyin "PRINTORGANIZER DELETE ALL" between the 2 "ADD" statements, the active file is loaded correctly at the second attempt.
I get the same results when executing the statements directly from within the "Key-in" dialog or even from within the PrintOrganizer dialog.
Also in case I use PRINTORGANIZER ADD FILE <myDgnName> <myStyleName>, the first attempt fails and the second succeeeds.
I'm quite sure I'm missing something trivial but I would really appreciate it if somebody could help me.
Using MicroStation Connect Edition, version 10.16.1.56
Since I thought that the active file might have been locked somehow, I tried copying the active DGN into a tempfile and then executing PRINTORGANIZER ADD FILE <myTempFile> <myStyleName>.
The copying of the file succeeds but unfortunately, I get the same result when adding that tempfile.
Another attempt: Don't specify the printstyle when adding the active file. Same error......
Hi Robert Kock,
Can you copy and paste (in your VBA project) a new method with keyins that uses CadInputQueue.SendCommand (KeyinCmd, True) vs. .SendKeyin (KeyinCmd) and see if that makes any difference?
Another similar test; since you are only doing key-ins and not programming (in this example) would be to place all those (consecutive) key-ins in a MicroStation Key-in Script File and only send (1) key-in to load and run those key-in script file stored in a text file using; e.g. @c:\scripts\mykeyins.txt.
First of all, thanks for your suggestion.
I tried both. I.e., replace SendKeyin with SendCommand (2nd parameter=True) and create/launch a Keyin script.
Unfortunately, I get the same result: the first attempt to load the active DGN fails and the second succeeds.
FYI. I will try as soon as I can to see if I can reproduce the issue and/or provide any additional recommendations.
Hi Robert Kock,
As a sanity test I tried performing a couple tests as outlined in the Print Organizer Key-ins help topic in MicroStation 10.16.02.22 that (to me) appears to be working fine when...
Can you try performing the exact lines as documented (using your dgn file names) and see if you can get successful results?
Also related are some similar steps listed in the Print Organizer Single Key-in to generate multi-page PDF wiki showing how to use configuration variables with the PRINTDESTINATION option.
Thank you and HTH,Bob
Our use of MicroStation is quite complicated. We have more than 100 MDL applications. Among them, there are some that design some specific elements on a dedicated level, open a separate view that shows only that level and allow the user to print that view.
When MicroStation is launched "our" way, we get the error I described before.
However, in another situation it does:
I save the DGN before pushing the 'Print' button (with the dedicated view open) and exit MicroStation.
After that, I launch MicroStation in the standard way, open the previously saved DGN and execute the various PrintOrganizer commands.
I get the PDF as expected.
In other words, there is some problem when launching MicroStation "our" way though it did work with V8i.
Probably something in one of our InputCallback::Set*Function callbacks or the
I've been searching the problem all day now but can't find anything suspicious. Getting crazy so I might as well start again tomorrow.
Thanks so far.
Understood and maybe some of these high-level suggestions may help isolate the issue(s) you are seeing when dealing with more complex designs/interactions. If you have not already, it may be best to consider adding some (more) trace logging (as evidence) between Good and Bad patient (runs) that can help you determine where to either: set debug break points and/or add additional logging details for conditions revealed when implementing your first pass of logging.
Some other considerations to review/verify that may be impacting the results may include:
Lastly, given the above if you can isolate the behavior in its most simple form consider creating a test case that we can inspect more closely to attempt to reproduce and make further recommendations.
It looks like I found the problem though I really have no clue what the actual problem is/was. I hope you can enlighten me:
When launching MS, we include -wusigra on the command line (sigra is the name of our system; not actually relevant).The file %MS%/config/appl/sigra.cfg contains the line %include $(SIGRA)/data/sigra-common.ucfThe latter contains configurations as MS_MDL, MS_DGNAPPS, MS_DGNLIBLIST, ecc.In case everything within this file in enclosed between %if !defined (_CONSOLEAPP) ... %endif, things work correctly.When I remove this %if ... %endif, we get the problem I described earlier.
Could you please explain why this might cause any trouble? I'm about to call a priest...
So it sounds like you are close to having a Good and Bad patient where you are potentially questioning what the differences are between configurations.
It appears that PrintOrganizer starts a non-graphic background process and requires (as a work-around) to update your configuration files to handle working in that non-graphic state for this application as explained here.
So, although I do not know any additional details on the need for it and if the work-around is not sufficient to help resolve the issue, the next step I could suggest would be to quickly and conveniently capture and compare both the good and bad configurations when processing the same set of files in the following manner:
Doing so could possibly help identify/indicate something that is present in Good.txt (certain variables/values; like MS_DGNLIBLIST) not present in Bad.txt that could be defined/added at a more suitable point in the configuration file processing (See: Configuration Blogs > Config Files and Config Levels) and help get past the need for the recommended work-around.
Answer Verified By: Robert Kock
Thanks for the explanation and the link in which the work-around is explained.
I don't feel like digging into it any deeper so I prefer to keep the work-around.