Just wondering if the sdk has available the ability to show the select property dialog that has the properties of a selected element shown and allow the user to select a property an return that selection.
Basically what you see when you add a field to text to show a element property.
thanks
JD
Do you want add a Field into a text by programming? If it is, please refer my below post on ChinaFirst programming forum. Although the talks are in Chinese, code are common.
https://communities.bentley.com/communities/other_communities/chinafirst/f/microstation-projectwise/180135/msce-c-textblock
took a look at that post but cant find any of that in the sdk help doc and those methods are not showing up in my c# code.
for example if I have a textblock I do not see a method for .AppendField. I don't see a TextField type anywhere either.
is this exposed in the .net sdk? or how would I get to these in c#.
You have to turn to C++ programming or use C++/CLI to wrap a DLL and then reference this DLL into your C# project to call these native code functions.
I was hoping that was not the case.
I'm not that great with c++. any help in how to set up a visual studio project to write my c++ functions. after I create the c++ project what do I have to set to link/reference the libs or headers files??
John Drsek said:I'm not that great with c++.
Be aware Yongan did not mention C++, but C++/CLI, which is different language: C++ is a language compiled to native code and standardized as ISO norm. In contrast to it, C++/CLI is Microsoft proprietary port of C++ into NET world.
C++/CLI is pretty ugly language in my opinion, merging not only good but also bad features of both worlds. But the unique and great feature is that a mixture of native and managed code can be done in one project, so it's often used, as Yongan wrote, to create wrappers between native and managed ... in other words, on one side it's possible to link and use native libraries, on the other to use such assembly as normal NET library.
John Drsek said:any help in how to set up a visual studio project to write my c++ functions.
Not C++ project, but C++/CLI. In Visual Studio it's CLR class library template I guess.
But I recommend in this case to ignore Visual Studio and to use bmake. To set up C++ project is not simple and to do the same for C++/CLI is even worse in my opinion. Bmake should setup everything for you and you can use mixed mode example(s) delivered with MicroStation SDK as a template.
What is not intuitive, because it requires good knowledge how memory is allocated in native code and how in NET, is to write managed wrappers around native classes properly. But in fact it's quite mechanical work and is well documented in many blogs and articles.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan thanks
I went down the c++/cli road before with projectwise and ended up just writing the wrappers in c# with dllimport. but with these functions i don't think I can do that.
so to make sure I understand what your saying is to not setup a Visual Studio project and just use bmake? what about debugging...
So is the mixed mode example a c++/cli
John Drsek said:ended up just writing the wrappers in c# with dllimport
Technically there is no difference between P/Invoke (dll import) and C++/CLI. But in C++/CLI you don't have to take care about proper marshalling and all other native/managed conersion, it's done automatically. And because your code is responsible for a class instance lifetime, you can implement memory (de)allocation exactly as necessary.
... in fact often the most of the wrappers code is to create native instance when managed class is created and to call native destructor explicitely when managed class is disposed.
John Drsek said:so to make sure I understand what your saying is to not setup a Visual Studio project and just use bmake?
It's just my preference. Whatever bmake does, you can also configure in Visual Studio, because at the end the same tools with the same parameters are called. Maybe it's just a heritage from V8i, when experienced a lot of problem with VS2005 used for C++/CLI projects and it was acceptably difficult and at the end working smoothly to use bmake.
I assume it's now easier with VS2017, but bmake would be my choice again (in fact it was already for one wrapper I had to create for I guess Update 4).
John Drsek said:what about debugging...
Debugging has nothing to do with what tool(s) was used to compile the assembly. When proper files (dll, pdb) are created, the debugging should not be any problem.