|
You can reinstall VC, or download newest sdk from Microsoft;
This is the fragment from mmsystem.h, which compiles:
<br />
<br />
#ifdef _WIN32<br />
typedef UINT MMVERSION; <br />
#else<br />
typedef UINT VERSION; <br />
#endif
Probably You have modified the code.
Hope that helps
|
|
|
|
|
I feel like such a choad.
Out of all the Win32 Common Controls the TreeView control has
given me the most grief and the documentation is not very helpful.
In this instance (of a long series of them) I'm having a problem
with the TreeView_GetParent function. Basically I'm trying to follow
a leaf in the tree back to it's root. And do so via the following
function:
<br />
void ConstructPath(TVITEM *item,char *buffer) {<br />
HTREEITEM back = TreeView_GetParent(Tree,item->hItem);<br />
if(back == NULL) {<br />
MessageBox(MainWindow,"doesn't have parent","recursed",0);<br />
}<br />
else {<br />
TVITEM *node = (TVITEM *)back;
char name[_MAX_FNAME];<br />
memset(&name,0,_MAX_FNAME);<br />
node->mask |= TVIF_TEXT | TVIF_CHILDREN ;<br />
node->pszText = (char *)&name;<br />
node->cchTextMax = _MAX_FNAME;<br />
TreeView_GetItem(Tree,node);<br />
MessageBox(MainWindow,name,"recursed",0);<br />
ConstructPath((TVITEM*)back,buffer);
}<br />
}<br />
When run this function screws up the display of the control and returns
the absolutely wrong nodes in the tree.
Now I'm going to hazzard an educated guess that "TVITEM *node = (TVITEM *)back;"
is the problem as back is an HTREEITEM that I'm casting to a TVITEM (which
TreeView_GetParent requires yet returns a HTREEITEM. I cannot find the
definition of HTREEITEM in the help system and hoping that GetParent was written
with recursion in mind the two types might not have been far off (I know bad guess  ).
Can anyone tell me what the relationshipo is between TVITEM and HTREEITEM and how I can convert one into the other (or at least point me to some clear documentation)? 
Sean
|
|
|
|
|
HTREEITEM is a handle to an item in the tree (similar to the simpler index value that can be used with list controls). TVITEM is a structure that can be filled with information about an item in the tree. You can't cast between one and the other, because they are not related (other than that HTREEITEM is a handle that can be used to fill a TVITEM structure via GetItem). HTREEITEM is not a pointer to a TVITEM.
While iterating through a tree (using GetParent, GetChild, GetPrevSibling, GetNextSibling etc.), you should use HTREEITEMs. In fact, most of the TreeView messages use an HTREEITEM to identify which item you're talking about. If you need to obtain more information about the item the HTREEITEM is referring to, use TreeView_GetItem. If hTree is the handle to the tree control you're working with, and hItem is the item you want information about, the following code could be used:
char name[_MAX_FNAME];
TVITEM itemInfo={0};
itemInfo.hItem = hItem;
itemInfo.mask = TVIF_TEXT | TVIF_CHILDREN
itemInfo.pszText=name;
itemInfo.cchTextMax=_MAX_FNAME;
TreeView_GetItem(hTree, &itemInfo);
After that code, the name array will contain the text of the item (up to _MAX_FNAME-1 characters), and itemInfo.cChildren will be 0, 1, or I_CHILDREN_CALLBACK.
"We are the knights who say Ni" (The Knights Who Say Ni)
|
|
|
|
|
Can I obtain the number of the last visible line in a CRichEditCtrl??
|
|
|
|
|
Hello!!
I want to retrieve the number of services (and their names) which are running in the system. I can do this with EnumServiceStatus() for OS NT-onwards. Can anyone please tell me how it can be done for Windows 98.
I also want to get the DeviceDriver information. The same information which is got by, EnumDeviceDrivers() and GetDeviceDriverBaseName() apis for OS Win NT onwards. I want the same info for system with Win 98. i.e.. I want the dlls and the sys file (or vxds) which are loaded in the system with Windows 98 OS.
Have a nice day
Sandeep
|
|
|
|
|
According to msdn:
Windows 95/98/Me provides a scaled-down Service Control Manager:
RegisterServiceProcess
RunServices
RunServicesOnce
Services are stored under:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion
It should contain:
MyApp1="myapp1.exe"
MyApp2="myapp2.exe" param1 param2
MyApp3="c:\mydir\myapp3.exe"
This is how You can retrieve number of services, and their names. The other problem, is whether those "services" are still running.
Mukkie
|
|
|
|
|
I have a CString like:
"C\I386\IAS.MDB", and I want to get dbName = "IAS.MDB" out of it. I dont see anything friendly in the class memebers of CString. Any hints? Surely CStrings must be equipped with these friendly extractions???
Thanks,
ns
|
|
|
|
|
What do you mean by friendly ? You can Find the /, then use Left, Right, or Mid to extract the substrings.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Thank God, your answer was not "use std::string".
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
*grin* although I generally use std::string, I'm not as pedantic about it as I am about vector/list/et. al. CString does useful stuff that std::string does not.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Yeah, thats right 
I tried hard for about three years to become comfortable with std::string, but then I gave up and since these day I use CString again. (I have extracted the CString sources from MFC, so I can use it even in non-MFC projects. However, these days you don't need to go this long way, because WTL includes also a CString implementation that can be used without MFC. And with the new VC7 template based CString class things got really nice.)
IMHO std::string is a bit overenegineered. To treat it as a general sequential container of characters of any type that has not to be null terminated is nice from the generic programming point of view (and I love generic programming and STL), but impractical.
I always missed things like GetBuffer() or Format() and other very string specific stuff. And I like that CString takes only 4 Bytes and you can even reinterperet this 4 Bytes as const char*. I like the automatic type conversion to LPCTSTR and that it does not crash if you assign it a NULL character pointer. And much more.
CString is the one and only thing of MFC that really rocks 
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
|
What about missing upper/lowercase conversions in std::string? And there's no real replace either.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
Tomasz Sowinski wrote:
What about missing upper/lowercase conversions in std::string?
That is one thing that std::string certainly lacks.
Tomasz Sowinski wrote:
And there's no real replace either.
A number of things are missing because it's assumed you'll use the algorithms the STL provides, which it plugs in to. But it is nicer having them all on the interface, one reason I tolerate CString, although I personally do not use MFC, and do not miss CString.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
A number of things are missing because it's assumed you'll use the algorithms the STL provides, which it plugs in to
Unfortunately, STL doesn't provide ready-to-use algorithm for string/string replacing in string, a'la CString::Replace(LPCTSTR, LPCTSTR). At least I don't know any - if you found one, let me know
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
Actually, I think you are right - at work we have a class called CSTring, which mimics the MFC CString and is derived from std::string. I hate it, but I use it when I need Replace....
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Daniel Lohmann wrote:
I tried hard for about three years to become comfortable with std::string,
Really ? I've only been coding three years. How hard did you try ?
Daniel Lohmann wrote:
I always missed things like GetBuffer()
It's called &string[0].
Daniel Lohmann wrote:
or Format()
Format is ugly - an ostringstream does a much better job, and the framework is extensible.
Daniel Lohmann wrote:
And I like that CString takes only 4 Bytes and you can even reinterperet this 4 Bytes as const char*.
You can do this with c_str().
Daniel Lohmann wrote:
CString is the one and only thing of MFC that really rocks
It is adequate and there are things it does better, but it does not *cane* std::string, they are about on a par.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Daniel Lohmann wrote:
I always missed things like GetBuffer()
It's called &string[0].
This does not help that much, because the standard does not ensure that the returned buffer is zero terminated 
Christian Graus wrote:
Daniel Lohmann wrote:
or Format()
Format is ugly - an ostringstream does a much better job, and the framework is extensible.
Oh yes - I tried this, too. But I found that most times I don't need the extensibility. Complex data types tend to do too much formatting for their output, so that it is only usable for debugging purposes but not for output to the end user. And those ostream concatenations tend to get really long and nearly unreadable:
printf( "Error %d (0x%x) in Module %s Line %d: %s.\n",
dwErrorCode, dwErrorCode, nLine, pszModule, pszMsg );
comes to
cout << "Error " << dwErrorCode << " (0x" << hex << dwErrorCode << ") in Module " << pszModule << "Line " << nLine << ": " << pszMsg << "." << endl;
I doubt that the above is really better to read, to write and especially to maintain.
Christian Graus wrote:
Daniel Lohmann wrote:
And I like that CString takes only 4 Bytes and you can even reinterperet this 4 Bytes as const char*.
You can do this with c_str().
No, you cant. I was not talking about conversion to LPCTSTR. The thing is that the memory layout of a CString instance is the same as for a char*. Thus one could write the following:
CString Text( "Hello World" );
TRACE("%s", Text );
Of course that is bad style, I only want to demonstrate the principle. The point is that it makes a lot of debugging tasks easier if you know that the 4 bytes representing a string point directly to the string buffer it manages - especially if you have to debug release builds...
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
|
Daniel Lohmann wrote:
the standard does not ensure that the returned buffer is zero terminated
YEs, I've actually noticed that it isn't when using the memory window. But if you want zero terminated, then you're reading, not writing. In that case, c_str() is fine.
Daniel Lohmann wrote:
And those ostream concatenations tend to get really long and nearly unreadable:
printf( "Error %d (0x%x) in Module %s Line %d: %s.\n",
dwErrorCode, dwErrorCode, nLine, pszModule, pszMsg );
comes to
cout << "Error " << dwErrorCode << " (0x" << hex << dwErrorCode << ") in Module " << pszModule << "Line " << nLine << ": " << pszMsg << "." << endl;
I doubt that the above is really better to read, to write and especially to maintain.
You're kidding, right ? How is (0x%x) easy to ready, and not error prone ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
YEs, I've actually noticed that it isn't when using the memory window. But if you want zero terminated, then you're reading, not writing. In that case, c_str() is fine.
I frequently need to read and write the same buffer. (I use a library that does a lot of in-place modifications of string buffers.)
Christian Graus wrote:
You're kidding, right ? How is (0x%x) easy to ready, and not error prone ?
I find it easy to read
Of course, one has to know the printf format types and flags, but if you know them it is a very compact representation of what you intend to do...
Sometimes I got the feeling I am a bit old-fashioned. 
(Actually the truth is, that I have learned C++ IO before I learned how to do it in C. Believe it or not: I was used to use ostream for quite a long time and then I moved to printf  )
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
|
Check out _splitpath().
CString strPath = "C\\I386\\IAS.MDB";
char* pFullPath = strPath.GetBuffer (0);
_splitpath (pFullPath, ...);
strPath.ReleaseBuffer();
I'm working on releasing my FileSystem class to CP, which will make stuff like this easy to do.
Btw, have you become "nss" now?
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Nope nss because its my home account. I wanted email to come here while I'm here, and you have to have another identity it appears for a different email(my experimentation). Thanks for that very interesting bit of code. Guess you're back now that the place has been cleaned up by the housekeeper ....
|
|
|
|
|
She spends 2-3 hours at my place (I'm a neat freak so it's easy to clean), but I spent most of the day at the bookstore and in search of food. Gonna lull myself to sleep with Petzold's C# tome.
I really should start posting articles again. I have a bunch of GUI helper code that would make the list control gymnastics you alluded to easy to do. Plus stuff for getting and validating edit controls, easily setting bunches of radio buttons, etc, etc. Stuff I got tired of duplicating in each project.
I'm going to crash now because I'm soooo sleepy. G'night!
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
...or alternatively you could use the Path functions in SHLWAPI. While _splitpath does this job, the Path ones will do some more difficult and tricky ones.
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
|
Thank you very much indeed!
ns
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
