|
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.
|
|
|
|
|
I am getting set to start a new project and was wondering if some of you guys could give me some
ideas on the best method to handle exceptions. Should I go with CException or something else? Any
idea is appreciated. Thanks for your time.
glguru
|
|
|
|
|
By default, CMDIChildWnd use all its client area for a CView object, but I want leave some space to place another things, for example RulerBars, what can i do for it?
Someone suggested me use two CDialogBars to implement it,but I don't think it is a good way, because the dialogbars can't overlap each other.
I want to set view orgin at CPoint(16,16) relative to ChildWnd's client area orgin. What can i do for it?
|
|
|
|
|
You should handle WM_SIZE and do the layout there.
Try something like this:
void CChildFrame::OnSize(UINT nType, int cx, int cy)
{
// CMDIChildWnd::OnSize(nType, cx, cy);
CWnd::OnSize(nType, cx, cy);
CWnd* pView = GetDlgItem(AFX_IDW_PANE_FIRST);
if (pView != NULL)
pView->MoveWindow(16, 16, cx - 16, cy - 16);
GetMDIFrame()->OnUpdateFrameTitle(TRUE);
}
In this way, you get the space for the other controls. You can even paint the rulers directly in the frame's client area and not use controls.
I would suggest you to use CControlBar-derived rulers too, but you decide.
|
|
|
|
|
How do I display the image from the file with any file format i.e the extension(*.bmp,*.jpg,*.jpeg) in the dialog box
|
|
|
|
|
Have a look at www.paintlib.de
|
|
|
|
|
Hi Freaks,
I have a problem with a template function in a DLL. This template function is a method of a class which is not a template class. The class is part of a DLL an is properly exported (all other (non template) methods work). When this class is part of the project where I call the template function from it works too. When I call the template function in my "main" project and the class is inside the DLL I get "unresolved externals". I know that I can solve this problem by making the non template class a template class, but thats not intended.
Has anyone a brilliant idea about that ???
Thanks for help in advance... cu
-=[SKULK]=-
|
|
|
|
|
Can you post some of the code? Might have a better idea of the problem if we can see it.
|
|
|
|
|
I have two bitmaps.
How do I stretchblt one into the other?
|
|
|
|
|
I am not sure, but this can be OS/display driver dependant:
Create 2 memory DCs. Select each bitmap in his corresponding DC, then do the stretchblt between the DCs. The bitmap in the target DC will be modified.
You can the bitblt the taget DC contents into another DC (like the DC of a control/window) or unselect the bitmaps, and do what you wish with the modified one.
|
|
|
|
|
Hi,
In my application, I need to call
::EnumChildWindows(m_hWnd, SetButtonState, (LPARAM)(Info));
How can make the following function to be local:
BOOL __stdcall SetButtonState(HWND hwnd, LPARAM lparam)
to be someclass' member function like:
BOOL __stdcall CMyApp::SetButtonState(HWND hwnd, LPARAM lparam) -----> this is wrong!
Some code sample will be much appreciated!!!
Thank you very much!
|
|
|
|
|
You don't. You can't pass a non-static member function because the parameter list doesn't match (remember in C++ all non-static member functions receive a hidden first parameter, the "this" pointer). What you can do is declare write your callback like this:
BOOl __stdcall SetButtonState (HWND hwnd, LPARAM lparam)
{
CMyApp* app = (CMyApp*)lparam;
ASSERT (app != NULL);
app->SetButtonState (hwnd, lparam);
}
Then call EnumChildWindows with the global SetButtonState, like this:
::EnumChildWindows (m_hWnd, ::SetButtonState, (LPARAM)&myApp);
The global SetButtonState just redirects each call back to the object that you specified in the call to EnumChildWindows
You could also make the global SetButtonState a static member of your class.
Cheers,
Eric Tetz
|
|
|
|
|
Hi,
I was wondering if anyone had an idea of how to implement a global undo feature.
Something like what microsoft offers with all of their applications. I have an application that does some
undoing, but I would like to convert this to handle any operation.
Any suggestion is appreciated...
|
|
|
|
|
|
Is there anyone out there using the ActiveX
web browser control IWebBrowser2?
I can't seem to get the horizontal scroll bar to go away?!?!?!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
