|
A tree control item doesn't have an index, since the tree doesn't represent a simple linear list. Each item in the tree has a handle. Using that handle, there are methods provided by the CTreeCtrl that you can use to change the item itself, get the child items, and so on.
Software Zen: delete this;
|
|
|
|
|
GetChildItem and related SiblingsApi
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Is there any rotatable tracker to use?
My current app needs it.
thx for any link and clue.
|
|
|
|
|
I don't know what you mean by "rotatable tracker"... could this imply that I am unable to help you?
|
|
|
|
|
This is not really a problem, just wondering if anybody else has encountered the same problem and how they deal with it. I use VC6 to code multilingual programs (English and Chinese simplified). I usually use the built in resource editor to create the dialogs/menus along with their text.
Here is where I usually encouter problems. The editor allows for the input of Chinese characters, though after compilation the exe incorrectly displays them. My way of rectifying the problem is to open the *.rc file in a text editor (UltraEdit) convert to unicode and save (though now VC6 reports it as being damaged), build clean, and no problem.
Is there a simpler way of doing this? Maybe I should also point out that I create a MBCS build and that the final build must be win98 compatible.
|
|
|
|
|
Open the .rc file as text, and in all your dialog resources, do this:
Change DIALOG to DIALOGEX
Change the FONT to "MS Shell Dlg"
Add the DS_SHELLFONT style
The VC6 resource editor predates these features, so you will have to re-do them after editing a dialog in the editor. Usually only the DIALOGEX part will be undone, so a simple search and replace of "DIALOG " with "DIALOGEX " (note trailing spaces) will fix it right up.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Thanks for that tip, works like a charm.
|
|
|
|
|
waldermort wrote: the final build must be win98 compatible.
Have you tried running it? W98 doesn't support Unicode programs so you need to use the MSLU.
RC files can be (IIRC) in UTF-8.
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall.
Awasu 2.2.3 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Thanks for the info. As stated in the origional post, this is not a Unicode build. Reencoding the resource file to UTF8 didn't solve the problem. The editor was able to open it, but the characters were still distorted.
|
|
|
|
|
Hi,
I have made a Project derived from CRichEditView and I want to paint the Client-Area.
The painting works perfectly there, is no flickering at all but there is a problem with the caret and the displayed signs. The caret appears completely strange and the displayed signs are not visible.
Here is all I added to my project:
BOOL CRichEdit2View::OnEraseBkgnd(CDC* pDC)<br />
{<br />
<br />
COLORREF crFgcol = 0, crBgcol = RGB(209,255,176);<br />
CRect rect;<br />
GetClientRect(&rect);<br />
<br />
CDC dc;<br />
dc.CreateCompatibleDC(pDC);<br />
<br />
<br />
CBitmap bmp;<br />
CPen pen;<br />
bmp.CreateCompatibleBitmap( pDC, rect.Width(), rect.Height() );<br />
pen.CreatePen( PS_SOLID, 1, crFgcol );<br />
CBitmap *pOldBitmap = dc.SelectObject( &bmp );<br />
CPen *pOldPen = dc.SelectObject( &pen );<br />
<br />
<br />
<br />
dc.FillSolidRect( &rect, RGB(255,255,255) );
CRect rcBar(rect);<br />
rcBar.top = 100;<br />
rcBar.bottom = 120;<br />
<br />
dc.FillSolidRect( &rcBar, crBgcol );
dc.MoveTo( rect.right - 1, 0 );<br />
<br />
pDC->BitBlt( 0, 0, rect. right, rect.bottom, &dc, 0, 0, SRCCOPY );<br />
dc.SelectObject( pOldBitmap );<br />
<br />
dc.SelectObject( pOldPen );<br />
return TRUE;<br />
}<br />
<br />
HBRUSH CRichEdit2View::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)<br />
{<br />
pDC->SetBkMode(TRANSPARENT);<br />
return NULL;<br />
}<br />
<br />
void CRichEdit2View::OnPaint()<br />
{<br />
CPaintDC dc(this);
}<br />
I would be really happy if someone has an answer for me 
|
|
|
|
|
Hello. I have a custom control that contains a couple of buttons. When I place this control into a dialog, it works fine for the most part, but when I set the dialog's 'Control' and/or 'Control parent' properties to true it hangs when I click on one of the buttons in the custom control.
Is hangs and seems to get stuck CWnd::IsDlgMessage.
Any thoughts on why that might be?
The structure of my dialog is the following...
PropertPageA contains: CustomCtrlA
CustomCtrlA contains PropertyPageB
PropertyPageB contains CustomCtrlB.
Anyone have any general thoughts or tips about that structure? I know that's a little vague, but I'm just wondering about how to ensure a setup like that all flows well together and creates properly.
Thanks for any help.
|
|
|
|
|
Hey guys, im trying to unmangle c++ decorated names. The code is below. I think there is something wrong. If i comment out the "printf("final : %s\n",final);" line, the output seems fine. Else now, it throws some garbage.
ANy help will do...thanks 
Cpp file
#include "mangie.h"
#include <stdio.h>
void main()
{
char *ac;
char *aa;
int a33;
char* final;
ac = "?hello@@YAXXZ";
*final = UnMangle_symbols(ac,aa);
printf("\n\n\n\n");
printf("final : %s\n",final);
}
char UnMangle_symbols(char *mang, char *unmang)
{
int siiiz;
char *errormsg = "Error";
//mang = "?hello@@YAXXZ";
if (UnDecorateSymbolName(mang,unmang,siiiz,UNDNAME_COMPLETE))
{
printf("Undecorated name %s\n", unmang );
return (char)unmang;
}
else
{
return *errormsg;
}
}
Header file
-------------
#include <windows.h>
#include <winsock.h>
#include "DbgHelp.h"
char UnMangle_symbols(char *mang, char *unmnag);
|
|
|
|
|
UnMangle_symbols returns a char. The line
*final = UnMangle_symbols(...);
assigns the character to whatever final is pointing to, but at that stage final has not been initialised therefore you are writing a character somewhere in memory (could be absolutely anywhere).
The print statement outputs a character string starting at where final points to, i.e. this unitialised memory. Hence garbage.
Try making UnMangle_symbols return a char* (but make sure that the string does not go out of scope (i.e. is not somewhere on the stack)), the assignment then becomes
final = UnMangle_symbols(...);
Graham
My signature is not black, just a very, very dark blue
|
|
|
|
|
I used to use Borland's IDE and they had a cool tool called an object browser (I think) which was analagous to an object-oriented pedigree. It is essentially an image of boxes representing classes and lines representing relationships (vis inheritance). I find it a much simpler way to visualize complex inheritance than the object browser included in MS's product. If there an add-in or this facility built in which I have just not discovered yet?
Thanks.
|
|
|
|
|
|
Take a look at DOxygen: http://www.stack.nl/~dimitri/doxygen
Here is an example of DOxygen graphical output:
http://xml.apache.org/xerces-c/apiDocs/inherits.html
|
|
|
|
|
Hi,
I have a big code base that has been developed for a while. Unfortunately, they did not use exceptions at all for floating point divde by zero. Fortunately, when I was using visual studio 6.0 I was able to get the debugger to jump in when such an exception occurs.
The problem is now we are migrating to visual studio 2003. There is an option to have the debugger jump in when a floating point divde by zero occurs (debug->execeptions or crtl+alt+e), but it does not seem to be working, atleast for a blank console application. Could this be because the application is a console application and not a win32 application? Or can we not rely on the debugger.
This is the simple program I used to test:
int main()
{
double x = 5.0;
double y = 0.0;
double z = x/y;
return 0;
}
What should occur is that the debugger should do something when it see x/y by jumping in. I have the option enabled: c000008e Floating-point division by zero and I set it to break into the debugger if the exception is not handled.
I know that we should be using try catches, but this is to test and algorithm and once again the code base is huge.
-- modified at 17:39 Friday 4th August, 2006
|
|
|
|
|
Ok I have solved the problem. With the following code snipet
#include <float.h>
#include <iostream>
int main( void )
{
_controlfp(0, _MCW_EM);
double x = 5.0;
double y = 0.0;
double z = x/y;
}
This will be caught by the debugger and an exception will be thrown. It seems that I had to unmask this option using _controlfp. I am not too familar with it but it seems to work 
-- modified at 18:42 Tuesday 8th August, 2006
|
|
|
|
|
I declared CMyApp like this:
CWinApp CMyApp;
How AfxGetApp() function locates the address of CMyApp?
|
|
|
|
|
AfxWin1.inl:
_AFXWIN_INLINE CWinApp* AFXAPI AfxGetApp()
{ return afxCurrentWinApp; }
AfxWin.h:
#define afxCurrentWinApp AfxGetModuleState()->m_pCurrentWinApp
AfxGetModuleState() returns a pointer to a MFC internal state structure.
AppCore.cpp:
CWinApp::CWinApp(LPCTSTR lpszAppName)
{
...
ASSERT(afxCurrentWinApp == NULL);
pModuleState->m_pCurrentWinApp = this;
ASSERT(AfxGetApp() == this);
...
}
So basicly the AfxGetApp() pointer is setup in the CWinApp constructor. If you really want to know the internals of MFC then thge best place to look is in the MFC source files. Using the visual studio debugger to step through the sources is the best way.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
When CMyApp is instantiated, the pointer to it is stored in an internal table. AfxGetApp() simply returned.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Does anyone mind briefly explaining what hard wired means in C++???
sorry if im asking childish questions 
Thanks guys
|
|
|
|
|
This is probably referring to values being 'hard coded'.
So if you have explicitly defined a numeric or string in your code, then it is termed as being 'hard-coded'.
The flip side of this is to construct your coding so that your values are user-defined, or can be obtained from an external source.
#define PI 3.142
float calc(int a, int b)
{
return (a * b * PI);
}
</code>
So in the above example, I have hard-coded the value of pi. In this case the accuracy of my calculations are fixed. If I needed to increase the accuracy of pi at a future date, I need to edit and recompile my code. This may not be a problem now, but can cause some problems in certain circumstances.
Hard coding string values are also widely mentioned and can be extremely difficult for multi-lingual software. In cases where your program messages, logs, reports and UI text may change (due to language changes for example), you do not want to hard-code text strings when writing your code. One way around this is to use the string resource files that de-couple this process.
I Dream of Absolute Zero
|
|
|
|
|
Hardwired[^] is often used to convey the concept of logic (i.e. control flow) that's "unchangeable" or "difficult to change".
/ravi
|
|
|
|
|
Adding to what other have posted, here are some examples of hardwired code:
void main(void) {
double cylinder_volume=5.5*3.1415*3.1415*7.9;
printf("The total cylinder area is %.15g\n", cylinder_volume*4.0);
long total_people_to_invite=10.0;
printf("The total invitations is %d\n", total_people_to_invite);
}
This code is hardwired to the extreme. Compare to the next code example:
#define PI 3.1415912
void main(void) {
double cylinder_radius=5.5;
double cylinder_height=7.9;
double cylinder_top_area=cylinder_radius*PI*PI;
double cylinder_volume=cylinder_top_area*cylinder_height;
double total_cylinders=4.0;
printf("The total cylinder area is %.15g\n", cylinder_volume*total_cylinders);
long singers=1;
long bartenders=3;
long dancers=5;
long cooks=1;
long total_people_to_invite=singers+bartenders+dancers+cooks;
printf("The total invitations is %d\n", total_people_to_invite);
}
This code is not as hardwired. Still, it could be coded to be even more flexible and reusable. For example, the area computation of a circle (used for the cylinder_top_area) could be implemented as a function which takes the radius.
In general, the sense of "hardwired" code is related simultaneously to how clear it is to read it, understand it, change it, and re-use it. The easier it is to acomplish those things *SIMULSTANEOUSLY* the less hardwired the code is.
In the above example all the predefined quantities could even come from some external configuration file, making changes easy even without recompilation. For the above example, this could be too much. So "hardwired" is not a clearly defined concept, but you see that if for such a simple example as the cylinder volume and invitation count external files had to be opened to read configuration parameters then, clearly, reading and understanding would be harder.
I hope this helps,
Rilhas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
