See the Comeau C++ Template FAQ: Why do I get a link error when compiling my templates?[^] -- I'm Michael Dunn and I approve this post. Vote Trogdor in oh-four!

its cooool man.. so u did it. ur correct, noncreatable does not prevent from queryinterfacing an interface. More specifically noncreatable attribute is for a coclass, not for an interface. It just prevents that coclass from being instantiated. Also, if u r able to queryinterface that interface from the activex IUnknown, then that terminal cleint interface is not a separate coclass and not noncreatable attributed. I revoked the defenition i had given for a non exposed interface. I rephrase it as just another interfaec under the activex coclass, apart from the activex dispinterface and its event dispinterface. What exactly it means is Scripting engins like Vbs need at least one IDsipatch derived interface. So normally COM servers that expect scripting engins as clients will always derive interfaces from IDispatch. But the limitation of COM is that a coclass can have only one IDispatch implimented interface.(Well, COM_INTERFACE_ENTRY2 is there to specify which Idispatch is 2 b considered) So if we need to have more than one interface in a coclass, then the remaining interfaces shud b iunknown derived (to make it compliant with vbs like apps). And As far as vb is concerned these IUnknown derived interfaces are "non exposed". That means vbs like clients can't get it directly, but they can queryinterface the IDispatch. If ur familiar with vb, u cud catch it easly. Or more clearly u can leave that term, it is specificaly for vb programmers we can say. BTW GetControlUnknown is just an alternative to invoke mthds on an activex. As per the msdn sample the vb code gets the terminal cleint interface thru the objectmethod. if such a method is there in the activex, then ofcource that method will be there in the wrapper class also. coz, as u said wrapper class is just an idispatch wrapper for invoking methods on the activex. So it will contain all the methods in the activex. if u do a search for "object" in the wrapper class header file, it will be there. if it is not there, then that msdn sample code is wrong. i don't have that control installed on my mechine. generate the idl of that ocx and chk for "object" in the idl. rgds...mil10

You want the ASP.NET Web Service. It creates a skeleton web service for you which runs under IIS. Ian Mariano - http://www.ian-space.com/ "We are all wave equations in the information matrix of the universe" - me

Antti Keskinen wrote: Has anyone here yet ventured into the world of Symbian or Series 60 development ? Yes! Antti Keskinen wrote: What tools do you use ? The Visual Studio 6 setup. Antti Keskinen wrote: As far as I know, the Series 60 SDK and it's tools are a piece of crap: a bunch of script-driven gcc-tools. They look worse when you start using them. After a while... Well, integration is not their forte... The tools are a bit crude, as you say. But if you look under the covers you will find some gems thet will make your life less miserable. Anyway, it's a sizeable learning curve... Good luck! Regards, João Paulo

"impossible idea that someone would still develop software for Windows 3.11 or earlier" Not develop, but maintain/add functionality. It was not until this last year that they finaly allowed me convert it to Win32 (95 or later). I've been writting software since before windows existed. As for button properties, may be it was just there way of resource code changes. After all adding a couple of new bit flags is simple and should not break any of the existing programs. Microsofts development teams do seem to have good reasons for most of the things they do, it is just hard to figure out (at times) what those reasons where. A lot of what they did was neccesary to avoid breaking old code and make it easier to convert old 16 bit Windows code to 32 bit Windows code. You'll notice that there are many references like "This is included to support... When developing for Win32 you should funcX". INTP

This problem seems to be related with the "Bind All" selection of the wizard. Leaving it out will cause the wizard to function flawlessly. Luckily MSDN is full of articles about dynamic binding, and the usage of RFX. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

Thanks for the reply ! Unfortunately, I couldn't find any ways to 'code this around'.. Any hints on where I could find such articles ? Like I described in my opening post, using a CDialog-derived class is NOT an option, unless you can tell me how I can specify a menu resource, a class name and a window name while building the dialog. Does the CDialog have a suitable overridden CWnd::Create for this purpose ? Greets, Antti ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

Note to self: "Experiment more before asking" FindWindow was the answer. Although it's a bit "odd" way of doing it, it works. Accompanied with a test to 'IsChild', and sure match is made. -Antti ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

Well, now it's a complete haxor :) Greetings, Antti ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

Well, it didn't work for me. The app description wasn't changed until I booted my machine. After that it started working properly again.. Weird stuff :) -Antti ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

um... my version of VC++ has an "MFC Appwizard" :~ - Nitron "Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb