[CONNECT C#] Show Element Property Selection Dialog

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??

Hi John,

I am confused a bit by this thread ;-)

I understand the original question as ability to access a list of properties, but it seems to change quickly to "add field to text" issue. So what issue is more important and valid?

I think (but have not tested it) to receive list of all properties for a specific element would be possible using ECQuery. And a dialog with such list can be quite simple. On the other hand, to implement dialog similar to that you mentioned will be probably complex task.

With regards,

  Jan

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

Jan,

yes my original question was for getting a dialog box of properties for a selected element to allow the user to select a property.

I know I can get all the properties and populate a simple dialog. but was just wondering if Bentley exposed that dialog in a method anywhere, where it would just return something like the access string after the user selects a property. sounds like no.

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:

but was just wondering if Bentley exposed that dialog in a method anywhere

Well, you know, API is designed to allow access to platform features primarily and not to user tools ;-)

The "field selection" dialog is implemented in TextTool.dll, but it's not pure NET assembly, so it's hard to guess whether it can be called from outside.

In "EC assemblies", there are plenty of classes to access, display and format EC data available, so I think the most of puzzle pieces is available already, but without some documentation, it's hard to guess how to put them together.

John Drsek said:

sounds like no

But at the same time it sounds like something that can be valuable for more people. So a reason for Service Ticket or an opportunity to develop own NuGet package? ;-)

With regards,

  Jan

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.

With regards,

  Jan