I'm working on an MFC ActiveX Control that implements some hidden properties.
The properties are hidden by adding the [hidden] attribute in the the ODL
file. Some properties are hidden because they have been replaced by newer
properties. By marking the obsolete properties hidden, new developers don't
see them but older apps can still access them programmatically.

This works fine for VB6, the properties do not show up in the properties
grid or object browser.

However, in VS.NET 2005, the hidden properties still show up in the
properties grid and object browser.

I've also tried the nonbrowsable attribute and the props still show up in
the props grid.

Any ideas?

Hi,

Which version of Visual Studio that you are using to create the MFC ActiveX
Control?

I haven't tested an ActiveX Control created in MFC but I have some VB6
ActiveX Controls which have hidden properties and they seem to work
correctly in Visual Studio 2005, both in an unmanaged MFC dialog
application and in a WinForm application.

Would you please post or send me your MFC ActiveX Control source code so
that I can reproduce the issue on my side? Thanks.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Walter,

Control is authored in VC++ 6.0 with latest service packs applied.

Source code was just sent to you by email.

The hidden attribute is mainly a hint to user-oriented object browsers. I suspect that historically it was driven by VB6 designers,
since as you discovered, VB6 honours that hint, but most other browser tools (including Visual Studio) ignores it.

Brian


"HairlipDog58" <HairlipDog (AT) nospam (DOT) nospam> wrote

Thanks.

I've done some research and I think I have found the root cause of this
issue.

There are two approaches to define a property in IDL/ODL, one is to use the
approach in your sample code:

[ uuid(5F9B1CFB-CBD0-4290-A74A-62080CDF50C1),
helpstring("Dispatch interface for HiddenPropTest Control"), hidden ]
dispinterface _DHiddenPropTest
{
properties:
// NOTE - ClassWizard will maintain property information here.
// Use extreme caution when editing this section.
//{{AFX_ODL_PROP(CHiddenPropTestCtrl)
[id(1), hidden] boolean Hidden;
[id(2), nonbrowsable] boolean NonBrowsable;
[id(3)] boolean Normal;
//}}AFX_ODL_PROP

methods:
// NOTE - ClassWizard will maintain method information here.
// Use extreme caution when editing this section.
//{{AFX_ODL_METHOD(CHiddenPropTestCtrl)
//}}AFX_ODL_METHOD
};


Another one is to use the approach what VB6 is doing using propget/propput:


[id(7), propget] BSTR P1();
[id(8), propput] void P1([in] BSTR rhs);
[id(9), propget, hidden] BSTR P2();
[id(10), propput, hidden] void P2([in] BSTR rhs);
};


Apparently the type library importer of .NET Framework can only deal with
the second approach. Following are the applied attributes to the member
from the generated interop assembly:

[DispId(1),
DesignerSerializationVisibility(DesignerSerializat ionVisibility.Hidden)]
public virtual bool Hidden
{
...


[DesignerSerializationVisibility(DesignerSerializat ionVisibility.Hidden),
Browsable(false), DispId(0x68030000)]
public virtual string P2
{
...



Note the second one has an attribute Browsable set to false, which is the
key to make it hidden in property grid.

To workaround this, I think we could use two different aproaches.

1) Change the IDL in MFC project to use propget/propput.

2) If you are distributing the interop assembly (see concept Primary
Interop Assembly, aka. PIA), you can first use ildasm.exe to get the IL
source code of your interop assembly, after modification, use ilasm.exe to
compile the IL source into assembly again.

#Customizing Primary Interop Assemblies
http://msdn2.microsoft.com/en-us/library/7112ksf7.aspx

#How to: Edit Interop Assemblies
http://msdn2.microsoft.com/en-us/library/8zbc969t.aspx


Hope this helps.

Hi Walter,

Thanks for the reply.

Seems like a bug in the .NET type library importer that should be addressed
by MS.

This is an established control. If I use approach 1, I think binary
compatibility would be broken by changing prop declarations from MFC
ClassWizard style to VB propput/propget style. Thoughts?

I'll have a closer look at approach 2, but still seems like unnecessary work
since all information is already available in ODL.

My guess is that there is a significant base of MFC-based ActiveX Controls
that have the same requirement, so seamless .NET support would be expected.

Hi Mark,

I'm sorry that my previously reply isn't complete, the approach I mentioned
is using a general COM component as an example. Actually in this case we
are dealing with an ActiveX Control and we can use a more simpler approach.

We can use AxImp.exe and its /source switch to generate a source file for
the Winform control wrapper and it's this file that we need to tweak with
and compile again. Please refer to following KB for detailed steps:

#PRB: Cannot Add ActiveX Control to Toolbox
http://support.microsoft.com/kb/320780

In the RESOLUTION steps, before the last step to compile the wrapper, apply
the System.ComponentModel.BrowsableAttribute(false) to the properties that
you need to hide from the property grid.

When distributing your control, you need to distribute three files: the ocx
file itself, the interop assembly, the winform control wrapper. Your users
can add the winform control wrapper to toolbox and use it from there.

Again, we're sorry for the inconvenience caused by this issue. I will
forward it to product team. For now, please test above workaround and let
me know if there's anything else I can help.



Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.