|
|
Thanks, Michael buddy!
Geo
|
|
|
|
|
In addition to Michael's post, if you are exclusively using C++, declaring variables as consts is the preferred method to defining constants. This is much more typesafe than using #define. Scott Meyers has more on why you would prefer this in one of his "Effective C++" books.
eg:
const short myNum = 100;
const double myOtherNum = 1.234;
etc etc
If you are using C or a mixture of C/C++ (ie , you are compiling one or more modules as C code), then this method does not work, so YMMV.
--
Ian Darling
"The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
|
|
|
|
|
I am sorry for having to ask such a stupid question but how do I check if an edit control is empty? I have tried comparing the contents of the window to NULL but that does not work. I have also checked to see if the CEdit class has an IsEmpty() type function and I can't fine one. Does anyone know how to do this?
Thank you all for your patience.
|
|
|
|
|
if (CMyEdit.GetWindowTextLength() == 0)
{
}
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
I have four octets of an ip stored as follows.
byte octet1,octet2,octet3,octet4
IPAddressCtrl.GetAddress(octet1,octet2,octet3,octet4);
What I need to do is get those four bytes into a DWORD in the propor byte order so I can store that DWORD in an SOCKADDR_IN structure like this
SOCKADDR_IN saDest;
saDest.sin_addr.s_addr = /*Somehow stuff octet1,2,3,4 in*/
Does anyone know how this can be done?
Thank you
|
|
|
|
|
Look at the MAKELONG macro.
|
|
|
|
|
...and if you are messing with network parameters don't forget that it uses network byte order (big endian). Use htonl() and ntohl() to convert between network and host byte order.
|
|
|
|
|
int CIPAddressCtrl::GetAddress( DWORD& dwAddress );
|
|
|
|
|
Hello,
Heres the situation:
I have a class MatrixN.
I also have a class VectorN.
Now, in MatrixN, some of the functions take a VectorN object as a parameter. In VectorN, some of the functions take a MatrixN object as a parameter.
When I try to include "VectorN.h" in MatrixN and "MatrixN.h" in VectorN.h I get an error of infinite recursion in include nesting. But if I dont include those files I get errors like:
(in VectorN.h) : syntax error : identifier 'MatrixN'
(in MatrixN.h) : syntax error : identifier 'VectorN'
Does anyone know what I can do to resolve this problem?
Thanx for the help,
-Flack
|
|
|
|
|
Use forward declarations, i.e. class MatrixN; in VectorN.h and vice versa.
Note that this requires that you use pointers or references in the interfaces.
|
|
|
|
|
Is there anyway of creating win32 threads and have them point to a class method. Such as:
#include "GpsControl.h"
#define WINAPI __stdcall
GpsControl::GpsControl()
{thread_handle = CreateThread(NULL,0,&GpsControl::GpsProc,NULL,CREATE_SUSPENDED,&threadID);}
unsigned long WINAPI GpsControl::GpsProc(void *)
{return (unsigned long) 2;}
I keep getting this error:
C:\kbrown\quat\GpsTest\GpsControl.cpp(8) : error C2664: 'CreateThread' : cannot convert parameter 3 from 'unsigned long (__stdcall GpsControl::*)(void *)' to 'unsigned long (__stdcall *)(void *)'
I really need the thread to use this function. Any Help would be MUCH appreciated.
DarkStar
Darkstar
|
|
|
|
|
|
|
Hi,
When I press delete key, I want to delete the selected node from the tree control in the sdi application. Do I need to use keyboard accelarator? How do I do it? any example?
Also, I want to popup a dialog which says Do you want to delete the selected node with yes and no option. Is there any custom way to achieve this?
Please Help!
Thanks in advance
|
|
|
|
|
|
Hi
Thanks for your reply. Can you explain a little more detail please.
1. Where do I handle The TVN_KEYDOWN notification. I have a formview and added the tree controls in that view.
2. MessageBox has following syntax from msdn, where is the option to add yes and no button?
MessageBox( LPCTSTR lpszText, LPCTSTR lpszCaption = NULL, UINT nType = MB_OK );
please help
|
|
|
|
|
Many times (just to keep my sanity) I'd scrap an entire project, create a new one and add back in ALL the files that were in the previous project and start afresh. That's because doing a compile in VC++ 6.0 after I may have made some changes to a file and renamed it, then delete the old file and add in the new one, VC++ or AppWizard (I don't know which is responsible) would start producing compile errors about being unable to open the new file (even though the file would be physically present in the same directory along with the other files.
I'm getting a little tired of having to recreate new project files everytime (and then go through the same routine) every time AppWizard detects a change to the workspace.
What's happening now is that I copied a file from another directory into the folder that contains the project I'm currently working on. Then from Project->Add to Project->Files, I added the new file I just copied, then recompiled everything with a "Rebuild All".
Guess what!!
In the ".cpp" file in which the "#include" statement for the new ".h" file is being used, AppWizard is telling me that it cannot open the new file (even though it's physically in the same folder, and has already been added to the project)!!
AAAAGGGGHHH. Curses. Curses. 
I can understand why some people shoot their computer!!
I ought to be able to add files, change files (etc.) without AppWizard acting up every time I do something like that.
Yes, I've also deleted the ".ncb" files (etc.) also.
Any workable solution would be unspeakably and indescribably appreciated.
Thanks.
William
Fortes in fide et opere!
|
|
|
|
|
This has nothing to do with AppWizard. AppWizard is simply a template based code generator. Once a project is generated, AppWizard plays no further part in the project.
Are you using quotes around the file to include, not braces? The presence of a header in the project has no bearing on the C++ search rules the compiler will follow.
I've replaced and renamed files in projects many times; just renamed a slew of files yesterday, and have never had a problem not of my own making.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
In one way you're correct that once AppWizard creates the application, its job is over (no argument there). The effects of what the application undergoes afterwards because of what AppWizard did at its creation, is what has lasting ramification on the program performances throughout the rest of its developmental process, which is where I am and what I'm experiencing.
Yes, I am very aware of the difference between using double quotes on filenames forming part of the "#include" statement, and those that use angle brackets. (Files obtained from libraries use the angle brackets and files NOT members of those libraries, use the double quotes.) I also know how files must be accessed depending on their physically location in the various directories (and along the directory path), and the same on information about libraries with regards to their locations and how they can be accessed.
It's what AppWizard puts in the ".dsp" file at creation that have me believing certain names originally used, must remained unalterable throughout the duration of the project. I have been burnt too many times on that point to believe AppWizard allows freedom in name changing, because if that were the case, ALL those times when I've had to recreate a ".dsp" file and then add back ALL the other files into the newly created project file, that would NOT have been necessary if freedom in name changing was totally allowed.
Thanks anyway for your input.
William
Fortes in fide et opere!
|
|
|
|
|
WREY wrote:
The effects of what the application undergoes afterwards because of what AppWizard did at its creation, is what has lasting ramification on the program performances throughout the rest of its developmental process, which is where I am and what I'm experiencing.
That's still incorrect. AppWizard simply creates a series of files, nothing more. Any ramifications are due to the MFC architecture and Visual Studio itself.
The files in the DSP file aren't much more than a list of files and any options associated with those files. It is entirely agnostic as to the name of files. Some of those files may have specific compiler options for them which will be lost if you delete a file from a project then add it again, but that's about it. (Precompiled headers is the big gotcha.)
WREY wrote:
(Files obtained from libraries use the angle brackets and files NOT members of those libraries, use the double quotes.)
This isn't entirely correct. If you quote the file to be included, the compiler will look first in the same directory as the file being compiled, then along the include paths in order. If you enclose the file to be included in braces, it only searches the include paths.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
This is a modal dlg spawned by another dlg. In its OnInitDialog I did a MoveWindow. The positioning is okay, but the dlg is rather large. Also the controls are not the way they look in the designer, where everything is centered. When I do Layout->Test its fine! But when it runs theres a big empty expanse with all my controls arranged on one side (like I arranged them in the designer). Its just that the dialog itself is too big, and the balnk space is to the right of my controls.
int width = GetSystemMetrics (SM_CXSCREEN);
int height = GetSystemMetrics(SM_CYSCREEN);
MoveWindow( width/2 - 200, height/2 -150, 300,200);
What do I do about this?
Thanks,
ns
|
|
|
|
|
ns wrote:
and the balnk space is to the right of my controls.
That makes sense. Increasing the size of the dialog won't move the controls. You need to do this yourself.
[edit]
Also, may I ask why you're increasing the size of the dialog if the control already fit? If it's a cosmetic issue, you should create a modeless dialog containing your controls (and all their handlers), then make the modeless dialog a child of the modal dialog. After resizing your modal dialog, simply center the child modeless dialog by doing:
MoveWindow (...);
m_modelessDlg.CenterWindow (this);
[/edit]
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
I wasnt clear. I mean that the dialog comes up weird even though at design time it looks perfect.
If I change the width of the window in the moveWindow:
int width = GetSystemMetrics (SM_CXSCREEN);
int height = GetSystemMetrics(SM_CYSCREEN);
MoveWindow( width/2 - 200, height/2 -150, 100,400);
from 100 to 200 or whatever, the dialog is always the same large size with the controls clustered to the left. In addition to my design view I am getting a bunch of blank real estate to the right.
|
|
|
|
|
ns wrote:
I mean that the dialog comes up weird even though at design time it looks perfect.
Yes, that makes sense. By calling MoveWindow() you're increasing the dialog's width and height, thereby adding a bunch of white space to the dialog's right and bottom.
If you want the dialog's controls to be centered after you call MoveWindow(), you need to write an OnSize() handler that repositions each control by (delta_x/2, delta_y/2). You'd need to add logic to compute the change in width and height (i.e. delta_x and delta_y). There are quite a few dialog resizing layout classes at CP that will do this for you. I can also send you my own (unpublished) one if you like.
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
