|
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
|
|
|
|
|
Hi,
I am writing a console application when I came across a problem where C++ would allow me to divide by zero when using doubles, but would not through out an exception. Is there anyway I can get the program to throw the divide by zero exception. Here is a sample program I made:
#include <iostream>
int main()
{
double x = 5.0;
double y = 0.0;
double z = x / y;
return 0;
}
The value of z ends up being infinity, but there is no exeception thrown and the program runs to completion.
|
|
|
|
|
You won't get an exception when dealing with floats or doubles. If you want to check for divide-by-zero problems, either check your denominator for values close to 0 or cast it to an int.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
Semantics changed since Visual C++ 7.1; structured exceptions (SEH) are no longer caught
When compiling with /EHs, a catch(...) block will not catch a structured exception (divide by zero, null pointer, for example); a catch(...) block will only catch explicitly-thrown, C++ exceptions.
Check MSDN for more information[^]
SaRath.
"Where I am from, there is no plan B. So, take advantage of today becuase tomorrow is not promised. - 50 Cent"
My Blog | Understanding State Pattern
Last modified: Friday, August 04, 2006 12:11:47 PM --
|
|
|
|
|
kpeng1 wrote: Is there anyway I can get the program to throw the divide by zero exception.
Here is a MFC example.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I guess I kind of phrased things wrong. I actually want the debugger to catch the divide by zero. I tried to enable the break into the debugger option in for floating points divide by zero and it does not break into the debugger. Any ideas?
|
|
|
|
|
Your best solution would be to do something like:
double x = 5.0;
double y = 0.0;
const double epsilon = 0.0001;
if (abs(y) < epsilon)
{
throw "Divide by 0!";
}
double z = x / y;
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
