XtremePropertyGrid class not registered

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Hello,

We're facing a somewhat obscure error that I believe is centered in a AxPropertyGrid (XtremePropertyGrid?) not being registered. It is exactly the type AxXtremePropertyGrid.AxPropertyGrid.

{"Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))"}    System.Exception {System.Runtime.InteropServices.COMException}

Is it a simple matter that we need to run one or more of our ActiveX / COM references through RegSvr32?

Of some note, this is occurring at the EndInit() in an InitializeComponents() method after the BeginInit() and initialization has taken place.

It seems like RegSvr32 should do the trick? I've also double checked our project(s) in the solution are targeting x86 and .NET 3.5.

Regards,

Michael

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
mwpowellhtx Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 19 April 2012 Status: Offline Points: 4	Post Options Post Reply Quote mwpowellhtx Report Post Thanks(0) Quote Reply Topic: XtremePropertyGrid class not registered Posted: 19 April 2012 at 10:21pm
	Hello, We're facing a somewhat obscure error that I believe is centered in a AxPropertyGrid (XtremePropertyGrid?) not being registered. It is exactly the type AxXtremePropertyGrid.AxPropertyGrid. {"Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))"} System.Exception {System.Runtime.InteropServices.COMException} Is it a simple matter that we need to run one or more of our ActiveX / COM references through RegSvr32? Of some note, this is occurring at the EndInit() in an InitializeComponents() method after the BeginInit() and initialization has taken place. It seems like RegSvr32 should do the trick? I've also double checked our project(s) in the solution are targeting x86 and .NET 3.5. Regards, Michael

mwpowellhtx Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 19 April 2012 Status: Offline Points: 4	Post Options Post Reply Quote mwpowellhtx Report Post Thanks(0) Quote Reply Posted: 20 April 2012 at 10:39am
	More research on the subject... It seems like we should be able to run TlbImp to import the type library from the OCX. We can do this and I land on an Invariant Language Interop output: 44 KB or so. (We're talking OCX version 9.6, so a little dated excuse us). Rummaging through our artifacts, there is also a Language Neutral Interop (?): 16 KB, which the previous build was using. How do we generate this? Also, the Invariant Language Interop in the previous build was: 52 KB and not 44 KB. So I'm confused. Should we be running what TlbImp against what Microsoft SDK to arrive at a sane output? Or does it matter as long as we're consistent, in our 64-bit x64 build environment, targeting our 32-bit x86 targets?

mwpowellhtx Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 19 April 2012 Status: Offline Points: 4	Post Options Post Reply Quote mwpowellhtx Report Post Thanks(0) Quote Reply Posted: 20 April 2012 at 11:06am
	Anyone? Anyone at all? I'll posit this: it looks like if we use Microsoft SDK v6.1 TlbImp, we're targeting .NET Framework 4. Not sure we want to do this, or we want to target 3.5 SP1 for sure (at least for the time being). Downloading 3.5 SDKs now. Will see if that helps with anything... Thank you...

mwpowellhtx Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 19 April 2012 Status: Offline Points: 4	Post Options Post Reply Quote mwpowellhtx Report Post Thanks(0) Quote Reply Posted: 20 April 2012 at 12:12pm
	Okay so for now, Ive triaged the issue by simply registering the OCX during the build process. Gets us by in the meantime. A little further out, I'd like to treat the Interop more like an intermediate output of the build process and have TlbImp import the correct interop for .NET Framework 3.5 and not 4.