How to get content plugin fields from the submenus.

[Lefteous]

2majkinetor !

This was the problem. Now I get the name of fields but units are still returned empty. Again, units are normaly returned with other plugins.

As you can read in the documentation units are optionally. ShellDetails never returns any units and many other plug-ins neither. Please note that TC automatically creates units for fields of type ft_datetime. Just use Shelldetails in TC and you'll see all this. No offense but should't you use content plug-ins for a while before starting a project which is based on this system?

2HolgerK
Your statement is a bit contradictory - once per thread or just once?

Why should the caller call this function although he doesn't know if COM is used in the DLL? CoInitialize is called once in my plug-in. If TC calls ContentGetValue in a new thread it's not called again.

[majkinetor !]

No offense but should't you use content plug-ins for a while before starting a project which is based on this system?

How cool
I must see to rise my children based on your parents example!

But you are actually missing the point of forum. If I used things "for a while" then I would certanly know everything I asked here, and thus this question would never appear. Thats how u become part of those that "used it for a while".

[Lefteous]

By using I actually ment using as a user not working with the plug-in interface as a developer.

[majkinetor !]

Well, it just happens that I never used units, as a user but I still want to use content plugins outsid of TC, the way I used them in TC.

Now, its not that unimaganable, is it, even for your strait-forward mind ?

[HolgerK]

2HolgerK
Your statement is a bit contradictory - once per thread or just once?

Why should the caller call this function although he doesn't know if COM is used in the DLL? CoInitialize is called once in my plug-in. If TC calls ContentGetValue in a new thread it's not called again.

The calling app is the thread owner, and must know about every new thread, if this thread will use COM-calls.

If "Yes" the thread must enter a COM-apartment, otherwise any use of COM may lead to unexpected results. It may work, but after a code change an error will rise up at a total different place. These bugs are very hard to analyze if you don't know that COM is involved.

The next decision is the COM apartment: STA or MTA?

GUI-Thread are always STA (CoInitialize or OleIntialize)
If the threads doesnt interact with the UI, MTA is an alternative (better performance for thread interop). You will need an different parameter in CoInitializeEx to enter MultiThreadedApartment!

Before the thread terminates a call to CoUnitialize is recommend.

Mutliple CoInitialize or CoUnitialize will only increase or decrease the reference counter but it's not recommend (see the link in one of my previous posts).
A call to CoInitialize can fail if the thread is initialized for MTA.

You see the point?
You don't know about the apartment from where the call into your plugin will occur.
On the other side the app-programmer is (maybe) not aware, that your plugin will do COM-Calls to do the job.
I think, you should document this for every programmer who will use your plugin.
Calling Coinitialize inside your plugin is imho not the right way.
This sounds more like a workaround to prevent the worst case.

Because it's a COMplex theme, here are some links:

MSDN: OleInitialize
MSDN: OleUninitialize
MSDN: CoInitialize
MSDN: CoInitializeEx
MSDN: CoUninitialize
MSDN: Process, Threads and Apartment
MSDN: Single-Threaded Aparments
MSDN: Multithreaded Apartments
MSDN: Choosing the Threading Model
MSDN: In-Process Server Threading issues

codeguru: Understanding COM Apartments, Part I
codeguru: Understanding COM Apartments, Part II (especially:Rule 1: Client Threads Must Call CoInitialize[Ex])

from the last codeguru link:

Rule 1: Client Threads Must Call CoInitialize[Ex]
Before a thread does anything that involves COM, it should call either CoInitialize or CoInitializeEx to initialize COM. If a client application has 20 threads and 10 of those threads use COM, then each of those 10 threads should call CoInitialize or CoInitializeEx. Inside these API functions, the calling thread is assigned to an apartment. If a thread isn't assigned to an apartment, then COM is powerless to enforce the laws of COM concurrency for that thread. Don't forget, too, that a thread that calls CoInitialize or CoInitializeEx successfully needs to call CoUninitialize before it terminates. Otherwise, the resources allocated by CoInitialize[Ex] aren't freed until the process ends.
...

Kind regards,
Holger

[Lefteous]

The calling app is the thread owner, and must know about every new thread, if this thread will use COM-calls.

Well this would require a function which informs the calling app about the fact that com is used (and the same for all other crappy technologies). But is not the case.
An alternative would be to trust that TC calls CoInitialize or to create one my own threads inside the plug-in.

On the other side the app-programmer is (maybe) not aware, that your plugin will do COM-Calls to do the job.

I think you are a missing some basic points.
Shelldetails is a content plug-in for TC. If anyone else wants to use the plug-in I'm not doing anything nasty to prevent use by other programs - but this is my decision as plug-in author. Creating a TC compatible environment is the job of the program.
The other point is that we are talking about a plug-in system. That means that multiple libraries are just loaded and have to work without executing any special code for a certain plugin.

I think, you should document this for every programmer who will use your plugin.

So if I write "hey my plug-in requires that the caller calls CoInitialiaze" Ghisler will have a look in the plug-in documentation and add support for it. This is not the way a plug-in interface works.