Don't know if this issue has been raised before. Sorry if I'm repeating something, but the Help!--->About Us section takes eons to open...not until I run out of patience :) can we get this fixed? Not that I use that page often, but here's an issue that bothered me and thought I'd bring it to notice Thanks... --Mayur

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can use 'GetComputerName' and 'GetUserName' to retrive name of computer and user name resp. Set/GetEnvironmentVariable API should help you work with the environment variables. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you keep the references in both the tables, you can improve the efficiency by eliminating joins. You can find all 'children' of a 'father' and vice versa by a simple query on a single table. The down side however is an additional overhead in maintaining the redundant data consistently. You need to make sure to update the respective fields whenever any child is to be deleted or the other way. Just see what is preferable for your application, efficiency or simplicity... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Marc Clifton wrote: They must do things differently in Europe It's not that more people will rush to the airport to travel by the A380. Instead, the existing crowd will be "crammed" into a single jet. So it's not the scene at the airport but that inside this craft that will be significantly different. Well, as you said, this might not be an airline for Europe, but should work wonders in Asia and on intercontinental routes connecting major hubs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dave Kreskowiak wrote: If just one of these things crashes, it'll become the worst air disaster in history, a record that required the collision of (2) 747's to set! Have we programmers become so nerd that we cannot think anything more than a 'crash'??? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Airbus A380 super jumbo took to the skies today. Wonder moments seeing the beauty take to the skies. [^] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now thats called true friendship ;P ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Well, the main point here is: We have razor sharp tools in the kit. If you can handle them, use it...else they'll hurt you bad ;P ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PJ Arends wrote: Using it is a design decision, not "bad design". Abusing it is bad design, but then abusing anything is I am in 100% agreement with you. Even the infamous 'goto' is cursed as a bad design paradigm. But circumstances govern their use in a few specialized cases. After all 'delete this' has certainly come to my rescue when I had to monitor the lifetime of an object using a reference counter similar to the COM classes. I seem a fair use of 'delete this' in such case. Also there are so many things in C++ that if abused screw up the program, better curse programming skill than curse a language ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Assuming you are not using smart pointers, the code will go as follows: { COSERVERINFO csi = {0}; MULTI_QI qi[1] = {0}; //Init pwszname to computer name of remote server where ur COM server //is to be deployed csi.pwszName = L"xxxx"; //use proper comp name here qi[0].pIID = &IID_IFoo; //Init to interface you wish to obtain HRESULT hr=CoCreateInstanceEx(CLSID_Foo,NULL,CLSCTX_REMOTE_SERVER,&csi,1,qi); if(SUCCEEDED(hr)) { m_pFoo=(IFoo*)qi[0].pItf; //you got the interface for remote machine. //Do your work here } } This method is to programatically set up the connection to remote server Another easy method is to register your COM server on both the local and remote machine. Launch 'dcomcnfg' on the maching you plan to run client. Find your COM server from the objects in the list view, right click and click 'properties'. Check the box 'Run this component on' and key in the name of the remote machine you paln to install your COM server. That should work fine. No significant changes are required to the basic functionality of the COM server and the migration to DCOM server should be breeze ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My COM server should fire the event of a VB client. The code (generated by the Wizard) is as follows HRESULT Fire_GetResult(VARIANT retResult) { CComVariant varResult; T* pT = static_cast(this); int nConnectionIndex; CComVariant* pvars = new CComVariant[1]; int nConnections = m_vec.GetSize(); ... ... The problem here is that m_vec.GetSize returns 0 and hence the for loop to fire the event is not called and return value is 0xCCCCCCCC However firing the event works intially and after a few function calls, it stops working! I am totally confused what could the problem be. Is it because of some memory leak or anything else. Please comment on possible problems. Also I would like someone to tell me whose responsibility it is to free the BSTR or VARIANT arguments in interface method, server or clients? for both by value and by reference type. Thank You Mayur Mahajan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:confused::confused: :| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ThatsAlok wrote: in what case IUnKnown is better and in what case IDispatch is better. The magic of IDispatch is apparent in automation clients. If you have a server implementing multiple interfaces along with support for automation, an obvious method would be to have a default IDispatch derived automation interface. The smart or VTABLE aware clients can well use the IUnknown derived interfeces. So the entire interface design scenario will be governed by the requirements of your server ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The man from SCN-CO wrote: Does anyone know which is a good utilities You may well use Cleansweep that comes with Norton Systemworks. It's a really resource consuming business but it works! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Changing or tampering NTOSKRNL.EXE to modify the bootup screen may not really be a good idea. I did end up locked off from my Win XP! So watch out. WinXP deals strictly with changed system files and will display some warnings every time this file is changed. I had this experience when I installed MacOS transformation pack. But beware that such custom packs may change quite a lot of system files and hence all your service pack updates might be rendered useless. So stick around with good commercial products (Designed for..... logo). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Steven Campbell wrote: when paid for by the companies that produce the products being tested I totally agree with you. The test conditions themselves are fallacious like the results. And really speaking I dont like my favourite Linux systems being ranked below those I don't really love and admire ;)

Maybe because I create a lot of errors in code and spend twice the time hunting for it ;)

Royce Fickling wrote: uuidof(ComServerLib::IMakeKey); U asked Royce to use __uuidof() instead of IID; Does this return the default interface? By this technique how can I query other interfaces of my COM object? Fortune favours the naive

I know COM is hard. And pointers in C++ is something people like to stay away :(. But I'm a c++ fan and like to get things done the hard way! Also using smart pointers is something like setting references in VB and too 'unornamented' ;P method to understand the workings of COM. /* And memory is sure to leak out of most progs unless u code with a cool head be it COM or C++ objects */ coding n debugging; two sides of same coin

A better and safe way other than smart pointers is invoking the COM runtime and obtaining interface explicitly. Compile the IDL file to get a '.h' and '.c' file. Using CoCreateInstance and QueryInterface methods you can get interface without breaking the code in VC++ 6.0 as well as 7.0. If you are hardcore C++ programmer I suggest you use this method rather than smart pointers. If the same problem persists with this method then it really is a problem I can get with. You can get lotsa tuts on codeproject to using COM without smart pointers. If u need the code lemme know, I hav efunctional client-server code running. May ur problem be solved with this!!! --:: VANDE MATARAM ::--