|
|
I am writing code and I am trying to use the simple TextOut(); function and I want to create a dynamic way to get the size of the LPCTSTR string rather than try to hard code it. I have tried sizeof() but that doesn't work any suggestions?
|
|
|
|
|
try "strlen" and its cousins.
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
Probably another simple queston.
I have used the same code in other dialog boxes, (with different variables)and it works.
Thanks for the help.
I get the following ASSERT at the line containing m_BeginStr.ResetContent();
_AFXWIN_INLINE void CComboBox::ResetContent()
{ ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd, CB_RESETCONTENT, 0, 0); }
void CDlgOffset::OnButtonBrowse()
{
FILE *StrFile;
CWnd* pWnd;
CString sStrName;
double E;
double S;
CFileDialog dlg( TRUE, "txt", NULL, OFN_FILEMUSTEXIST, "Text Files (*.txt)||\0" ,NULL );
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
m_StrFile = dlg.GetPathName();
pWnd = GetDlgItem( IDC_EDIT2 );
pWnd->SetWindowText( m_StrFile );
// Load the Combo Boxes
StrFile = fopen( m_StrFile, "r+");
fseek( StrFile, 0L, SEEK_SET );
m_BeginStr.ResetContent();
m_EndingStr.ResetContent();
while( fscanf( StrFile, "%s %lf %lf", sStrName, &E, &S ) != EOF )
{
m_BeginStr.AddString( sStrName );
m_EndingStr.AddString( sStrName );
}
fclose( StrFile );
}
}
|
|
|
|
|
has m_BeginStr been initialized? chances are that it isn't yet a "window" (and the ::IsWindow test is failing). make sure you're either DDX'ing the control or SubClassing it (ie. attaching an actual control to the variable)
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
it has CCombobox attached to it in the member varibles.
|
|
|
|
|
look in the DoDataExchange function of your dialog. do you see a line that looks something like this:
DDX_Control(pDX, IDC_MY_COMBOS_ID, m_BeginStr);
?
if not, it needs one. otherwise, the member variable is never actually attached to the control.
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
It is there.
void CDlgO::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CDlgOffset)
DDX_Control(pDX, IDC_COMBO_END_STR, m_EndingStr);
DDX_Control(pDX, IDC_COMBO_BEG_STR, m_BeginStr);
|
|
|
|
|
hmmm.
can you put a breakpoint on that DDX line and step into the DDX_Control code to see if anything fails?
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
it fails before it gets there.
Kevin
|
|
|
|
|
This question concerns the various C++ and corresponding header files that you would normally combine into a single project workspace folder. I'm somewhat mystified (but, I'm new to C++ and Visual C++,...everything is mysterious) as to the reasoning behind creating numerous separate files (both C/C++ and the definition headers) for a given project, except maybe convenience. As a novice to C++ programming, I find it much more educational to review the actual code than to read descriptive textbook style explanations of the various objects and functions. Currently, I am reading through Petzold's Programming Windows, which is excellent for a beginner like myself, but, I am curious as to why so many separate code files are necessary in a small, simple project as are presented in Petzold's book.
My main assumption is that for code and object re-use, it is convenient to have files that can be just added with an #include directive. I am wondering if in some circumstances it is preferred to have a definition header or series of such files for some specific configuration (I can't imagine what). Do I sound confused? I'm not even sure how to phrase to question.
Also, is it critical as to what order these various files are added to the project file? I am unclear as to what operations that compiler actually performs on these files besides scanning the syntax and creating a hierarchy of elements and instructions.
Anyone that could please just recommend an article that I could refer to, or a subject listing in the MSDN library, I would appreciate it hugely. Thanks.
|
|
|
|
|
you mentioned both of the answers:
1. code resue. you can't really reuse a class in another project, if it's definition is hidden away in a .CPP somewhere.
2. convenience. if your project gets much past the HelloWorld stage, you'll start to end up with classes and modules that have logical distinctions. for your own sanity, it's best to move those into separate files to keep the parts as manageable as possible.
no, it the order in which you add them to the project doesn't matter. VC will scan them and determine the dependencies automatically so that they are built in the right order.
-c
“losinger is a colorizing text edit control”
-- googlism
|
|
|
|
|
Chris,
Thanks. I thought it would be more complicated.
|
|
|
|
|
First off, Petzold's "Programming Windows" is completely written in C. While C is very similar to C++ in syntax and many other features, it lacks support for classes and it treats structs slightly differently so be aware of this fact.
The include files are where you will generally define your consts, global functions, classes and such, and the CPP file is where you will implement them. By defining your code in an include file, you will be able to reference the things defined in the header in a number of different CPP files. This model also facilitates code re-use.
The only time that the include order is important for the header files is when a header file that is defined, depends on a previous header file being defined. Usually the header that depends on another header will include it itself, however there are cases where the order is important, especially if you use ATL.
It is actually the preprocessor that scans through the header files. In fact, the #include directive, directs the preprocessor to extract all of the text from the file that has been included, and insert that text in place of the #include directive. So you could picture all of the files that you include, as being inserted automatically for you as if you had pasted them there yourself. After the preprocessor runs, then the compiler goes through and compiles each CPP file individually.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Paul Watt,
Thank you, this is exactly what I was looking for. I had done some searching at the MSDN site, but could not find that specific information. What I did find was information about the build process and how Visual C++ scans and interprets the file identifiers and translation units.
|
|
|
|
|
i am running my service on a computer and i want to know wheather a system is in logoff or login state?
how to get its state?
r00d0034@yahoo.com
|
|
|
|
|
Anybody got any ideas here? I have an active X control on a form view, and I am trying to do the following, with less than impressive results:
hWnd hWndControl = GetDlgItem(IDC_ACTIVEXCONTROL);
UINT nID = GetDlgCtrlID(hWndControl);
nID is equal to 0. I had hoped it would be equal to IDC_ACTIVEXCONTROL.
A dollar for anyone that can make this work.
|
|
|
|
|
I'm trying to use FindResource like this:
<br />
hResInfo = FindResource(NULL, "IDB_LOGIN", "Bitmap");<br />
I've tried "BMP", "RT_BITMAP", and RT_BITMAP as the type, but it still always fails. What am I doing wrong?
Thanks!
|
|
|
|
|
Try
<br />
hResInfo = FindResource(NULL, MAKEINTRESOURCE( IDB_LOGIN ), RT_BITMAP );<br />
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
Thanks, that works! Unfortunately, the OleLoadPicture in LoadFromBuffer in CPicture (www.codeproject.com/bitmap/cpicture.asp) fails 
|
|
|
|
|
I have a subclassed CListBox class (the name is CMyListBox).
class CMyListBox : public CListBox
{
...
virtual void DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct);
...
};
The problem is that the overloaded virtual void DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct); member function of my class will never called!
How can I fix that?
(I am working with Embedded Visual C++ 3.0 + PocketPC / PocketPC 2002 + MFC)
Daniel 
---------------------------
Never change a running system!
|
|
|
|
|
You should:
a) make sure the listbox in question has the ownerdraw checkbox checked
b) make sure your declaration of DrawItem looks exactly like the one in the baseclass.
If this does not help then I'm afraid I can't either 
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
The problem is that the same code does run perfectly under WinXP, only under CE (PocketPC / PocketPC 2002) the code doesn't run!
Daniel
---------------------------
Never change a running system!
|
|
|
|
|
From MSDN's WinCE pages:
"Windows CE does not support owner-drawn list boxes, so you cannot specify ODT_LISTBOX in the CtlType member of a DRAWITEMSTRUCT or a MEASUREITEMSTRUCT structure."
You should be able to use an ownerdraw CListCtrl though.
“Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002
|
|
|
|
|
I’m using Microsoft Layer For Unicode on 98. I’m not using any of CCM_Get/SETUNICODEFORMAT messages. Some of the common control as property sheet acts weired when I use IE 4. If I upgrade to IE 5, every things works as expected. I could not find any Microsoft documentation which says that I’ve to use IE 5, with UNICODe support. Is there any documentation on this?
I guess it is requirement to use IE 5 with UNICOWS, but I was hoping to find some doc to justify this
Thanks
Kasturi
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
