Basically you've got SOAP or old good TCP as default transport. You can buid your own if you want to (I do not know how easy it is to do). Remote instantiation is similar to DCOM (I am not going into details here). But they do have Web services as a prebuilt solution. Docs on remoting were quite bad for beta1. Did not check them in beta2, but I wouldn't expect them to be much better. Frankly, .NET still has to prove itself as a viable framework for distributed applications. If it happens then C# could be a good candidate for component-based distributed application development as well as an obvious choice for ASP.NET development Regards, Andrei Zenkovitch

C# would be my choice hands down for writing component-based software for .NET (ASP.NET, distributed applications). While .NET provides infrastructure, C# has features that make it a breeze to write components (notably, events). Another plus of this language is that it is easy to "read". I don't think C# is good for thick clients though. And not because .NET Windows Forms are inadequete (although they are not as rich as all the extention classes in MFC realm). It is just the fact that a thick client achitecture usually involves some sort of a framework that it is built around and I did not find C# particular good at designing frameworks (generics would be good here) Regards, Andrei Zenkovitch

Well, MeasureString have been broken in Beta 1 (it returned invalid result for some fonts). They fixed this problem in Beta 2. Still this function might be inadequate for precise measurement. I agree that .NET does not have enough power as far as text output goes (fonts, measurements). E.g. writing fully managed text editor with support for variety of fonts is an uphill battle (I would even say it is impossible). The only solution is to use P-Invoke to call into Windows SDK functions. I suspect that due to the fact that .NET is supposed to be appealing for cross-platform development they couldn't include any "Windows specific" functionality. Regards, Andrei Zenkovitch

Alex, I don't think that constness makes compiler to produce a faster code. Your example shows how using a reference as a parameter instead of a value type makes your code faster. As far as using const is concerned it only states that particular value type, pointer or referenced variable (value or object) cannot be changed; or if const is applied to object method (you cannot use const with static or global functions) it states that such function doesn't change internal state of such object. In other words it makes your design clearer by clarifying your intentions Regards, Andrei Zenkovitch

Cristi, Your code will not compile because m_xHiddenThing is a private variable and can be accessed only within the type it is declared in - class A. If it was declared using protected modifier then it would be possible to use the suggested code. That is why you have to be very careful while declaring private members without exposing them through protected or public functions Regards, Andrei Zenkovitch

Of course you are right. m_pSlots is array of pointers. Value of m_pSlots is the location of array in memory so it can be safely casted to a pointer to the array element type (in your example SLOT**). So if array declaration can be formally defined as ElementType array[TheNumberOfElement] dynamic creation can be formally defined as ElementType* array=new ElementType[TheNumberOfElement] and effectively array can be interpreted as a pointer to ElementType. Then the pointer to array must be only interpreted as a pointer to a pointer to ElementType

You might also try strtod() function. Regards, Andrei zenkovitch Dundas Software

I would send WM_QUIT message to the main window of a running application if I wanted to close it. WM_CLOSE message might be a good choice as well. These are two messages that could be used to kill an application nicely. If application is still running then it is highly probable that some overkill solution like TerminateProcess() function is used. Regards, Andrei Zenkovitch Dundas Software

Chris, Try to handle WM_ACTIVATE message. Dialog itself doesn't get focus. Instead when dialog window is deactivated it remembers the child window that had focus last and when it is activated the dialog will set focus to that child window. Regards, Andrei Zenkovitch Dundas Software

Hello! Include a handler for WM_KILLFOCUS message in your CWnd derived class that you use for subclassing edit box. in this handler you have to call SetFocus function to gain focus back to the control. Alternatively you can handle EN_KILLFOCUS notification in the edit box' parent window. In the handler for the notification you have to do the same - set focus back to the edit box using SetFocus() function. Regards, Andrei Zenkovitch Dundas Software

Hi, It is pretty easy to display a non-rectangular window by using SetWindowRgn() function. The painting of the background of any window using a bitmap is a bit more difficult as long as you would probably need to work with DIBs (Device Independent Bimap) but shouldn't be that big of a deal. As for the GUI toolkit you might take look at the Dundas (www.dundas.com) Ultimate Toolbox (it has classes that handle irregular shaped windows and background painting). or you might try to find some free classes on this site that will help you to solve your problem Regards, Andrei Zenkovitch ================== The original message was: Hi, where I can find a GUI toolkit to build graphical GUI like Winamp (non-rectangular dialog, bitmap)

Thanks

Hi, If you create list boxes explicitely using create function then make sure that you didn't specify LBS_EXTENDEDSEL or LBS_MULTIPLESEL style. If you use dialog editor for creating the template for your dialog then you have to display a property dialog for the list box control. On this dialog you have to select the second page "Styles" and in the "Selection" combo box you have to choose "Single" item Regards, Andrei Zenkovitch Dundas Software ================== The original message was: I have a dialog based app with three listboxes. I used AddString("") to add several items to
each string. When I run the program, it allows me to select all the items at one time. I
want the user to only be able to select one item at a time. How do I do this?

Thanks,
Stephanie

New Open File dialog is available only on Windows 2000 and in order to use it you have to use new version of OPENFILENAME structure that is defined in platform SDK 2000 as following: typedef struct tagOFN { DWORD lStructSize; HWND hwndOwner; HINSTANCE hInstance; LPCTSTR lpstrFilter; LPTSTR lpstrCustomFilter; DWORD nMaxCustFilter; DWORD nFilterIndex; LPTSTR lpstrFile; DWORD nMaxFile; LPTSTR lpstrFileTitle; DWORD nMaxFileTitle; LPCTSTR lpstrInitialDir; LPCTSTR lpstrTitle; DWORD Flags; WORD nFileOffset; WORD nFileExtension; LPCTSTR lpstrDefExt; DWORD lCustData; LPOFNHOOKPROC lpfnHook; LPCTSTR lpTemplateName; #if (_WIN32_WINNT >= 0x0500) struct IMoniker **rgpMonikers; DWORD cMonikers; DWORD FlagsEx; #endif // (_WIN32_WINNT >= 0x0500) } OPENFILENAME; The new element of this structure that you will be primarily interested in is FlagsEx. It can be set to the following value: <<<< OFN_EX_NOPLACESBAR If this flag is set, the places bar is not displayed. If this flag is not set, Explorer-style dialog boxes include a places bar containing icons for commonly-used folders, such as Favorites and Desktop. >>>> Regards Andrei Zenkovitch Dundas Software ================== The original message was: Does anybody know what to do to use the new Open File Dialog
that is now standard on Windows 2000 ? My app works fin on
W2000 but the Open File Dialog looks exactly the same way as
under Windows 95/98/NT.

Thanks

New Open File dialog is available only on Windows 2000 and in order to use it you have to use new version of OPENFILENAME structure that is defined in platform SDK 2000 as following: typedef struct tagOFN { DWORD lStructSize; HWND hwndOwner; HINSTANCE hInstance; LPCTSTR lpstrFilter; LPTSTR lpstrCustomFilter; DWORD nMaxCustFilter; DWORD nFilterIndex; LPTSTR lpstrFile; DWORD nMaxFile; LPTSTR lpstrFileTitle; DWORD nMaxFileTitle; LPCTSTR lpstrInitialDir; LPCTSTR lpstrTitle; DWORD Flags; WORD nFileOffset; WORD nFileExtension; LPCTSTR lpstrDefExt; DWORD lCustData; LPOFNHOOKPROC lpfnHook; LPCTSTR lpTemplateName; #if (_WIN32_WINNT >= 0x0500) struct IMoniker **rgpMonikers; DWORD cMonikers; DWORD FlagsEx; #endif // (_WIN32_WINNT >= 0x0500) } OPENFILENAME; The new element of this structure that you will be primarily interested in is FlagsEx. It can be set to the following value: <<<< OFN_EX_NOPLACESBAR If this flag is set, the places bar is not displayed. If this flag is not set, Explorer-style dialog boxes include a places bar containing icons for commonly-used folders, such as Favorites and Desktop. >>>> Regards Andrei Zenkovitch Dundas Software ================== The original message was: Does anybody know what to do to use the new Open File Dialog
that is now standard on Windows 2000 ? My app works fin on
W2000 but the Open File Dialog looks exactly the same way as
under Windows 95/98/NT.

Thanks

Derive your class from CButton. Then you have to guarantee that your button is always created using BS_OWNERDRAW style (if button is created explicitely using Create() function you might override PreCreateWindow() in order to do that, otherwise when button is being subclassed, e.g. in DDX/DDV engine, you have to override PreSubclassWindow() and put there an assert that checks for BS_OWNERDRAW style). As long as BS_OWNERDRAW style is set Windows will send your button WM_DRAWITEM message in which you have to draw the button. MFC provides virtual DrawItem() function that you need to override in order to handle WM_DRAWITEM message. From this point you are on your own in terms of providing drawinf implementation and handling the mouse and keyboard input in any specific way (of course, if you need to). Above mentioned details of implementation are valid only if you use MFC in your development. Using straight SDK you would need to take basically the same steps. But of course you need to handle all corresponding messages (WM_CREATE, WM_DRAWITEM) explicitly in your window procedure. Regards Andrei Zenkovitch Dundas Software ================== The original message was: How can I derive (superclass) my own class of windows from standard BUTTON class, for example, and change its look (for example: buttons and other controls in Microsoft Money).

Derive your class from CButton. Then you have to guarantee that your button is always created using BS_OWNERDRAW style (if button is created explicitely using Create() function you might override PreCreateWindow() in order to do that, otherwise when button is being subclassed, e.g. in DDX/DDV engine, you have to override PreSubclassWindow() and put there an assert that checks for BS_OWNERDRAW style). As long as BS_OWNERDRAW style is set Windows will send your button WM_DRAWITEM message in which you have to draw the button. MFC provides virtual DrawItem() function that you need to override in order to handle WM_DRAWITEM message. From this point you are on your own in terms of providing drawinf implementation and handling the mouse and keyboard input in any specific way (of course, if you need to). Above mentioned details of implementation are valid only if you use MFC in your development. Using straight SDK you would need to take basically the same steps. But of course you need to handle all corresponding messages (WM_CREATE, WM_DRAWITEM) explicitly in your window procedure. Regards Andrei Zenkovitch Dundas Software ================== The original message was: How can I derive (superclass) my own class of windows from standard BUTTON class, for example, and change its look (for example: buttons and other controls in Microsoft Money).

Hi John, There was a very good article on this topic in MSJ (it was published in 1996, unfortunately I don't remember the month). Anyway you can find the copy of the article on MSDN CD. You just have to search the library for: "SHAppBarMessage" or "Jeffrey Richter". The title of the article is "Extend the Windows 95 Shell with Application Desktop Toolbars" Regards, Andrei Zenkovitch Dundas Software ================== The original message was: Does a SHAppBarMessage wrapper exist? I would like to implement a ApplicationBar, and was just wondering before I go and write one myself.

Thanks in Advance
John Mancini

Hi Steve, The problem has to do with the fact that when CDialog tries to create a dialog window from the resource template internally it does by calling ::CreateWindowEx() function. The most important argument in this function is the name of the window class (like "Static" for static control or "Edit" for edit control). It is required that before window is created its window class must be registered. MFC does it internally for common controls but not for rich edit control which implementation resides in different dll. So when you call DoModal() function the internal Windows implementation will fail to create the rich edit control and therefore the creation of the dialog will fail as well. Now how to fix the problem. You just have to load the dll that contains rich edit control implementation in your InitInstance() function: HINSTANCE hRichEdDLL=::LoadLibrary(_T("RICHED32.DLL"); if(g_hRichEdDLL==NULL) TRACE(_T("Cannot load library to display RichEditTextControl")); Regards, Andrei Zenkovitch Dundas Software P.S. I assumed you were using MFC. If it is not the case then above mentioned explanations are still valid. ================== The original message was: I'm using VC++5. I find that when I use the resource editor to put a Rich Edit control in a dialog that is used either as part of a property sheet or as a dialog started from a menu option that the DoModal dialog callreturns -1 indicating that the box could not be created. (The same thing happens in VC++6). I searched the help and found no mention of any such limitation - it seems logical to be able to do it as the control is in the toolbar in the resource editor. I guess I must be doing something wrong. Any ideas?

Steve