Well, I just learned something new today... a good thing for an 'old guy' like me. I discovered that MicroStation V8i handles its display quite differently than previous versions.
Using the DirectDraw engine, it's constantly 'healing' the display, showing only the elements that exist in the model's database. For developers like us, we often create temporary display elements as 'user-helpers', so this display-healing that takes place automatically removes our temporary elements from the display! Nice feature, I guess...
Anyway, after spending a couple of hours trying to figure out why my temporary elements, that had been working in every version of this MDL app since MicroStation SE, were now not working, I learned about 'transient' elements.
Transient elements are special elements that are created within the DGN database, they're just not actually added to the DGN file. An example of a transient element is the little cell-origin cross that's created when you use the DEFINE CELL ORIGIN command. The element is persistent, but it doesn't physically exist.
The transient element works in a similar manner to the element descriptor, meaning that it can be complex and can consist of many smaller elements. The important thing to note is that you must create a single transient element and leave it defined while your application is running (ie. make it global), because if you free it up at any time, you lose your transient elements and they immediately disappear. There is a globally defined msTransientElmP that you could use if you choose to, but I wouldn't recommend it because MicroStation also uses the same register, and as soon as you activate a command that uses transient elements (any 'measuring' function, for example), you lose your transient element. In other words, create it, populate it and leave it until you either need to recreate it, or free it when the application closes. As long as the transient element exists, MicroStation will automatically display it.
The functions that you would use to manage them are the mdlTransient_xxx functions, and you can find an example app at http://communities.bentley.com/products/microstation/microstation_v8i/f/19569/p/37765/83839.aspx#83839 (look for Mark Anderson's 'romanboysurface.zip'.
till next time!
Shawn
occasional ponderings of a MicroStation application developer
Wednesday, September 7, 2011
Wednesday, October 6, 2010
Back in the Saddle
Well, after an extended period of being primarily back into the Drafting world (I am an architectural technologist by background and formal training), I'm now spending as much time writing code again as I am actually drawing things. I don't seem to have 'lost it', my MDL apps are working like they're supposed to, so that's good to know.
The project that I'm working on right now requires MicroStation v8 2004 Edition interfacing directly with Oracle 10g (not through ODBC). For my in-house development I decided to use the free Oracle XE 10g database. After some trials and tribulations, I've managed to get it working and I decided to start this blog in order to share what I've learned SO NO ONE ELSE NEED REPEAT THE MARATHON OF PAIN.
According to the tech support guys at Bentley Systems, V8 2004 (and XM) has a bug in the Oracle library that doesn't allow a remote connection with Oracle XE. No joy there...
There is however, a solution, although a bit roundabout.
If you install Oracle XE on the same machine as MicroStation V8, you're fine; everything works as it's supposed to. The problem occurs if you want to use the Client to connect to a remote Oracle XE server. Firstly, don't use the Client, it won't work. If you install XE onto the same machine as MicroStation, it has the necessary services and client files that will allow you to connect to a remote server. The catch is that the local database must be actively running, even though you're not using it. It just means a little more system overhead that's not serving a really useful purpose.
The second challenge that I ran into which caused much teeth-gnashing and hair-pulling was the fact that I was getting commas instead of decimals from my real number queries on the database. Caused all kinds of 'too many arguments' errors that drove me nuts (the main application has been working in a production environment since 1998, I knew it was correct). I then proceeded to spend many, many hours trying to get my output showing decimals for my decimals. I changed my Regional settings to all 'US English' (I'm in Canada and we spell things slightly different sometimes), but no change. I uninstalled and reinstalled Oracle (3 times) including full system boots between each install. No luck.
I finally came across an obscure blog posting somewhere, much like this one will be, which hinted that Oracle XE actually doesn't use the OS display parameters, it uses frigging INTERNET EXPLORER! I dropped my CDN English dictionary and switched to US English and everything worked.
ATTENTION MICROSOFT & ORACLE: Here in Canada we speak English and we use '.' for our decimals!
I'm going to continue posting the odd and unusual things I come across in my coding efforts as I find them.
Have a good one.
Shawn
The project that I'm working on right now requires MicroStation v8 2004 Edition interfacing directly with Oracle 10g (not through ODBC). For my in-house development I decided to use the free Oracle XE 10g database. After some trials and tribulations, I've managed to get it working and I decided to start this blog in order to share what I've learned SO NO ONE ELSE NEED REPEAT THE MARATHON OF PAIN.
According to the tech support guys at Bentley Systems, V8 2004 (and XM) has a bug in the Oracle library that doesn't allow a remote connection with Oracle XE. No joy there...
There is however, a solution, although a bit roundabout.
If you install Oracle XE on the same machine as MicroStation V8, you're fine; everything works as it's supposed to. The problem occurs if you want to use the Client to connect to a remote Oracle XE server. Firstly, don't use the Client, it won't work. If you install XE onto the same machine as MicroStation, it has the necessary services and client files that will allow you to connect to a remote server. The catch is that the local database must be actively running, even though you're not using it. It just means a little more system overhead that's not serving a really useful purpose.
The second challenge that I ran into which caused much teeth-gnashing and hair-pulling was the fact that I was getting commas instead of decimals from my real number queries on the database. Caused all kinds of 'too many arguments' errors that drove me nuts (the main application has been working in a production environment since 1998, I knew it was correct). I then proceeded to spend many, many hours trying to get my output showing decimals for my decimals. I changed my Regional settings to all 'US English' (I'm in Canada and we spell things slightly different sometimes), but no change. I uninstalled and reinstalled Oracle (3 times) including full system boots between each install. No luck.
I finally came across an obscure blog posting somewhere, much like this one will be, which hinted that Oracle XE actually doesn't use the OS display parameters, it uses frigging INTERNET EXPLORER! I dropped my CDN English dictionary and switched to US English and everything worked.
ATTENTION MICROSOFT & ORACLE: Here in Canada we speak English and we use '.' for our decimals!
I'm going to continue posting the odd and unusual things I come across in my coding efforts as I find them.
Have a good one.
Shawn
Subscribe to:
Posts (Atom)