|
I'm working on the same thing
You could get a handle to the DUN window etc
Or its possible to use the performance statistics,
If you care to know more e-mail me.
Regardz
Colin Davies
taxpaid@bigfoot.com
|
|
|
|
|
What is the proper way to throw and catch exceptions without using MFC?
I am supposed to derive my own class from std::exception, use with win32 command RaiseException() or do I just create my own exception class?
Which is the preferred method?
|
|
|
|
|
What is needed to draw on a device context
CDC dc;
dc.LineTo(10,10);
i'm new to this so how should this peace of code look like ... what am i missing
|
|
|
|
|
Well where are you getting the DC from??
Typically if you use an override of the virtual CView::OnDraw(CDC* pDC) method, the framework provides you the device context. From there you simply use it!
CMyView::OnDraw(CDC* pDC)
{
pDC->MoveTo(50, 50); // Line start
pDC->LineTo(10, 10); // Line end
pDC->Ellipse(0,0,100,100); // Draw a circle.
|
|
|
|
|
isn't it possible to create my own device context to play around with ... in any member function
void MyClass::myfunc(int i,int a)
{
CDC dc;
dc.LineTo(10,10);
}
|
|
|
|
|
Usually, you will want to draw in a window's device context. As Paul said above, you will get such a DC in handlers like OnPaint() or in OnDraw() for views.
If you have a window, you can get the window's DC using GetDC(), draw into it, then use ReleaseDC().
As a rule of thumb, at least for the beginning, try to keep the painting stuf in OnDraw(). You can call from there helper functions, giving them a pointer to the provided DC (pDC is fine).
Also, you can create a "memory DC", which basically behaves like a normal DC, but you will not see the results. However, you can copy (blit) the contents of such a DC into a normal window DC. Also, you can use a memory DC to draw on a bitmap.
For example:
CDC dc;
dc.CreateCompatibleDC(NULL); // creates a mem DC compatible with the display.
... // paint here, etc.
dc.DeleteDC();
Other device context are related to printers, metafiles, etc.
|
|
|
|
|
thank you all for your replies ...
all i wanted to do is have a memory DC on which i would put a bitmap and manipulate it around and then put it on the device context i get in the OnDraw() ... the problem i ran into was that the memory context is 1x1 (as it should be i guess) but how can i do LineTo or FloodFill if it is of that size
|
|
|
|
|
You have to create a bitmap and select it in the memory DC first. Once you selected your bitmap, all drawing changes it directly.
See also the GDI section for examples of usage.
|
|
|
|
|
Add the GetDC() call from a CWnd derived class or you will have to pass it a windows handle.
void MyClass::myfunc(int i,int a)
{
CDC * pDC = GetDC();
if ( pDC )
pDC->LineTo(10,10);
}
|
|
|
|
|
What is needed to draw on a device context
CDC dc;
dc.LineTo(10,10);
i'm new to this so how should this peace of code look like ... what am i missing
|
|
|
|
|
How to make a button on a toolbar pushed in to stay that way until otherwise needed ... like ie. paint in windows where the brush stays pushed while in use
|
|
|
|
|
Give the button the TBSTYLE_CHECK style. (Note - that constant was renamed to BTNS_CHECK in SDKs that shipped after VC 6.)
|
|
|
|
|
Hi, I'm using ImageList_Duplicate() to duplicate an Image List. This works fine on Win98 however on W2K the duplicated image list is incorrect. ie. It is not an exact copy of the source Image List. So far I've only seen this on W2K with the IE5.5 Beta installed so it is possibly that the IE5.5 beta has installed a bugy common controls DLL. I've not been able to try it on W2K without the IE5.5 beta yet.
Any help much appreciated.
|
|
|
|
|
In Visual Basic,put TabCtrl ocx on the form,and you can
put other ocx on the TabCtrl ocx, but VC don't.
Mustn't I create other ocx on TabCtrl dynastily?
if so,it is too terrible? anybody know?
|
|
|
|
|
The computers my app runs on are set for 8 bit color. I am able to display images and simple
line graphics just fine. Now I want to add a dialog box which uses the same colormap. I want
to display different sections of text on the dialog in different colors with different color
backgrounds. Of course, all colors come from the same colormap as the main app.
When I override the OnCtrlColor for the dialog, I select and realize the same palette as the
application. But it does not make a difference. The colors appear wrong. Sometimes they
appear dithered. Any ideas?
Thanks,
Mike
|
|
|
|
|
Hi !!
I am facing a wiered problem . When I copy all the files (.cpp, .h . rc, all files in res & debug folder) of a VC++ application created by one pof my friendsto my PC from a different PC , the VC++ Intelligent editor is not providing me the help. Whereas if I create a blank workspace and add the project file of the copied files to this blank workspace the help is available !! Can any \body tell me WHy is this SO ?? Is there any project setting needs to be done before distributing the source code ??
Thanks in advance,
Manjunath
|
|
|
|
|
You need to also copy the .dsw and .dsp files which contain the Workspace and Project informatio. The use File|Open Workspace to open the project.
|
|
|
|
|
Whenever I have IntelliSense problems, I can usually fix it by closing the workspace, deleting the .NCB file, and then reopening the workspace.
|
|
|
|
|
Is your friend also including the .clw (class wizard ) file?
|
|
|
|
|
Greetings,
I am new to Visual C++. I would like to know the naming conventions of the controls.
For example, in the sources on this site, the button controls are called m_button1 or something.
I would like to also know what p before a variable is and what b is.
Thanks
Rob
|
|
|
|
|
The Hungarian prefixes are:
p = pointer, eg pu = pointer to a UINT
b = boolean (Microsoft uses f instead, meaning "flag". MS uses b for byte. If you use b for boolean, use by for byte.)
As for naming of controls, what I do is make the name short but descriptive. Eg, if I have a list control I might call it m_FilenameList or m_ItemList. I don't like using Hungarian for controls, but that's just my personal preference. m_listItems just seems awkward to me.
--Mike--
|
|
|
|
|
Typically I use a modified form of Hungarian Notation.
As an example a if I have a dialog with a button
resource ID of IDC_APPLY and a label of Apply, I would have a tendency to call the variable m_wndApplyButton
the "m_" means it is a member of the class (a dialog class in this case).
"wnd" most controls are actually windows of one sort or another
"Apply" which is its function
and finally "Button" because it is.
Note: The specifics of a Naming Convention are really unimportant. What is important is that there is ONLY ONE Convention, that it is well documented, it is supported by all users and it must be consistently applied to all projects.
|
|
|
|
|
The two previous responses are right on target. Both have said that the exact nature of the convention is less important than that you use one and that it be clear. I could not agree more.
The Hungarian notation identifies the type of the variable: m_iNumber would be a member variable of type int, m_fNumber would be a type float. Like the other two responders, I don't use it. I do use the m_Var form to indicate it is a member variable.
What also is important is that variable names be descriptive: showing what they do, what is their "purpose in life." This is purely a "code readability" issue but, with optimizing compilers, I make it a point to (for the most part) format my code specifically for readability and let the compiler worry about speed and size.
|
|
|
|
|
The importance of a naming convention is directly proportionate to two things:
A) the amount of code you write and need to maintain/understand at a later date.
B) the number of people involved in A.
I program by myself for my own company, I can easily write a thousand lines of code in a day if I'm really humming. It's absolutely critical to me that I use a naming convention. On the other hand if I'm writing a little one shot utility that has maybe 10 variables in it I might just call them all x or y or something because I just don't care. It's hard to misplace a couple of variables in a one function dialog box.
On the other hand for any of my commercial work there is a distinct possibility that down the road if I am successful I just might be hiring someone else to work on that same code. If it's difficult for them to understand I'm going to end up paying them a lot more so it makes sense if your cheap as well. 
Personally I do it like this:
m_ prefixes any variable thats a member of a class and visible anywhere in that class (declared in the header not within a function itself).
m_p denotes a member variable that is a pointer.
ed in front of edit box names
btn in front of button names
ck in front of checkboxe names
dt in front of date/timepicker control names
lbl in front of static label names
cb in front of combo box names
rs for recordset names
b for a bool
n for an int
f for a float
str for a CString
etc
So for example I might have: m_btnExit, m_edSalary, m_dtStartDate, m_bIsEditing, m_pstrPassedString etc.
I know at a glance what they are, what they are for and where they are declared (their scope).
And most importantly of all use the EXACT same name everywhere on a large project or you will find yourself squinting at code and zoning out late at night. It's amazing how much time careful naming will save when you have a big job to do and your tired.
I have wasted lots of time when I have done somthing silly like called a dialog resource edit box "IDC_DATE" and then called the variable "m_edStart" or something equally unrelated.
For example I have a hypothetical edit box that is used to enter a first name, I would name it along these lines
IDC_FIRSTNAME for the resource, m_edFirstName for the CEdit control variable.
I don't recommend calling everything a window because thats kind of obvious and doesn't help much when you have a lot to do. It doesn't really matter how you do it, but whatever you choose to do stick with it. If your going to apply for work anywhere programming for a larger company, you should probably find the most popular hungarian naming convention and learn that because it seems to me it might just be one of those silly things a recruitment person might use to weed out prospects.
Just my 2 cents worth.
|
|
|
|
|
This forum is for developers only, and so any off topic or commercial posting will be removed.
I have not posted any "Conditions of Use" for these boards as yet so I apologise for any misunderstandings that may have occurred.
If a posting is made that you feel is in bad taste or breaches common courtesy then please let us know.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
