Article Writing

>>why bother with an add-in? Because it does not require NDA... >>It's not clear what you would want the Add-In to do. I want it to perform the basic operations on the open documents to begin with, also tell me the status, install watches on the file etc. Later on it can evolve of course... >>To me, running WinCVS and switching between it and VC IDE is no pain. To me it is, and more-other, it is dangerous! We already have two accidental removal of the files from repo, and some missing changes as well. It is not correct to launch the external tool to do the job. This is good example of something I call UNIX syndrom (with all respect) - why I need a windows, I have a command line!? The truth is that the command line tools are powerful indeed, but without the GUI wrappers are source of troubles. That is why you like WinCVS, isn't it? So, to stuff the thing into your IDE environment is just the same thing, but gives even more security! This is the next step, and the only way to make the job done. Yes, I don't like CVS. But if I have to use it, I will use it properly, make it working for me, not me working for it. Because it is a computer who is going to do the job, not me wasting my time and doing the things should be done automatically. Simple. COMPUTER IS FOR SERVING THE HUMAN, NOT THE HUMAN IS TO SERVE THE COMPUTER!!! Otherwise, we don't need this things at all, lets just use pencil and paper!? ================== The original message was: If you don't want to hook up with the MS SCC API, then why bother with an add-in? To me, running WinCVS and switching between it and VC IDE is no pain. It's not clear what you would want the Add-In to do.

>>why bother with an add-in? Because it does not require NDA... >>It's not clear what you would want the Add-In to do. I want it to perform the basic operations on the open documents to begin with, also tell me the status, install watches on the file etc. Later on it can evolve of course... >>To me, running WinCVS and switching between it and VC IDE is no pain. To me it is, and more-other, it is dangerous! We already have two accidental removal of the files from repo, and some missing changes as well. It is not correct to launch the external tool to do the job. This is good example of something I call UNIX syndrom (with all respect) - why I need a windows, I have a command line!? The truth is that the command line tools are powerful indeed, but without the GUI wrappers are source of troubles. That is why you like WinCVS, isn't it? So, to stuff the thing into your IDE environment is just the same thing, but gives even more security! This is the next step, and the only way to make the job done. Yes, I don't like CVS. But if I have to use it, I will use it properly, make it working for me, not me working for it. Because it is a computer who is going to do the job, not me wasting my time and doing the things should be done automatically. Simple. COMPUTER IS FOR SERVING THE HUMAN, NOT THE HUMAN IS TO SERVE THE COMPUTER!!! Otherwise, we don't need this things at all, lets just use pencil and paper!? ================== The original message was: If you don't want to hook up with the MS SCC API, then why bother with an add-in? To me, running WinCVS and switching between it and VC IDE is no pain. It's not clear what you would want the Add-In to do.

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).

There isn't a big reason for this anymore...windows will automatically anti-alias text if users want it to. However, check out the Win32 source of the Gimp program for an example (http://user.sgic.fi/~tml/gimp/win32/).

There isn't a big reason for this anymore...windows will automatically anti-alias text if users want it to. However, check out the Win32 source of the Gimp program for an example (http://user.sgic.fi/~tml/gimp/win32/).

What exactly are you looking for - any particular subject on CHTMLView ? ================== The original message was: I dream to find a very good CHTMLView article. May be one day .........

What exactly are you looking for - any particular subject on CHTMLView ? ================== The original message was: I dream to find a very good CHTMLView article. May be one day .........