|
I have one VC++ projects which was build on VS2003 on japanese windows XP OS, but when i compile same program on VS2003 English XP,i have found syntax error related to ; { }.
My code contains some japanese characters as string. Is it necessary to compile project on japanese OS only?
Thanks
Atul
|
|
|
|
|
It shouldn't matter which OS you are compiling on. It is probably an issue with code pages. You may need to save the source file in UTF-8 format before you compile.
If this still has problems, can you post a code sample and the errors so we can see what is happening.
|
|
|
|
|
am 2009 wrote: ,i have found syntax error related to ; { }.
We cannot guess what these errors might be, please show your code and the related messages.
am 2009 wrote: My code contains some japanese characters as string.
This should not be a problem as long as you have the Japanese language pack installed.
The best things in life are not things.
|
|
|
|
|
Have a look at this article
http://msdn.microsoft.com/en-us/library/b6ewb9fy.aspx
modified on Tuesday, May 10, 2011 4:56 AM
|
|
|
|
|
Link is not correct. Page not found.
"Every Little Smile can touch Somebody's Heart...
May we find Hundreds of Reasons to Smile Everyday... and
May WE be the Reason for someone else to smile always!" (ICAN)
|
|
|
|
|
The safest thing to do is have only ASCII in your source code, and use escape sequences (like \x1234) for characters outside of the ASCII range.
--Mike--
Dunder-Mifflin, this is Pam.
|
|
|
|
|
As I tested, in the 3 cases, server receives OnClose() event:
1. client calls Close()
2. client exits app - Close() should be called in client destructor.
3. server send string to client after Close() was called by client.
Are there other cases that server receives OnClose() event?
E.g. (from google) if internet unplugged on client side, server doen't receive OnCloe() - I use local IP address, so I can't test the case.
.
|
|
|
|
|
Basically OnClose() event is recieved to notify that the connected socket is closed by its process.
It can happen due to following: -
1) Network subsystem failed
2) Connection was reset by the remote side
3) Connection was aborted due to timeout or other failure.
Try to fit your test cases here...
CHEERS!!!
|
|
|
|
|
I did following 2 tests:
char*psz=0;
sprintf(psz,"%d",10);
class MyClass
{
public:
CString GetName()
{
return "Hello";
}
};
MyClass*p=(MyClass*)10000;
p->GetName();
in first test, app crashed and no idea to try-catch it.
in second test, GetName() is called properly without any problem (funny).
My Q is:
how to detect, catch or provent crash from invalid pointers as tests above, or other common cases?
.
|
|
|
|
|
includeh10 wrote: how to detect, catch or provent crash from invalid pointers as tests above, or other common cases?
This might work:
MyClass *p = (MyClass *) 10000;
if (! IsBadReadPtr(p, sizeof(MyClass))
p->GetName();But I've heard it can be unreliable, too. See here for more discussion.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Both BadReadPtr() and BadWritePtr() can detect it is an invalid pointer, thanks.
|
|
|
|
|
|
In case 1 you injected a memory address fault which is not, as far as I am aware, a catchable exception.
In case 2 you have created an object pointer of your class, which allows you to call any methods of the class. You will only get a failure if you attempt to access any instance variables of the object. However, again this would be a memory address fault, which is not catchable.
The best things in life are not things.
|
|
|
|
|
the first few memory pages (starting at adr zero) are never mapped into a process, therefore accessing them (such as when dereferencing a null pointer) will be trapped by Windows.
Address 10000 seems to be beyond those special pages, and is likely to exist within your app, therefore you may well be able to read there, while it is not recommended writing there!
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: Address 10000
gives an access violation. I think it is still well outside of 'user' address spaces.
The best things in life are not things.
|
|
|
|
|
IIRC adr 0x1000 (and hence also 10000) can be inside or outside of the regular process map, most of the map can be user selected through linker directives or switches. However the first few pages are always set aside as a protective measure.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
You're are wrong (even if you're always right!), jschell answer below is correct.
The code
p->GetName();
simply works because there's no usage of the implicit passed this pointer inside.
Try, for instance:
#include <iostream>
using namespace std;
class A
{
int a;
public:
void play(){cout << "Hi Luc!" << endl;}
void game_over(){cout << a << endl;}
};
int main()
{
A * pa = 0;
pa->play();
pa->game_over();
return 0;
}
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
sometimes you are right too, and this seems to be one of them.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
includeh10 wrote: in first test, app crashed and no idea to try-catch it.
You tried to write to an address which was not allocated as writable memory to your application.
The operating system detects that and issues a system exception for the application.
includeh10 wrote: in second test, GetName() is called properly without any problem (funny).
You are calling a method via static binding. Static binding in the code of your application is normal for your application.
The method itself is in the code space. Thus legal as well.
The method doesn't address any illegal addresses so no problem.
> how to detect, catch or provent crash from invalid pointers as tests above, or other common cases?
Find or buy libraries which detect memory problems, of many types.
Build your application with those.
Then run your application testing ALL of the code paths (there are other tools that track that.)
The library will tell you about improper memory usage.
|
|
|
|
|
|
Hi
I have a problem with an MFC Project that opens an email template, and sets some user properties on the mail item. The code I have been given with is as follows:
SetProperties()
{
LPDISPATCH userProps;
outlookmailitem->InvokeHelper(0xf816, DISPATCH_PROPERTYGET, VT_DISPATCH, (void*)&userProps, NULL);
COleDispatchDriver* outlookUser = new COleDispatchDriver(userProps);
LPDISPATCH userProp1;
static BYTE params[] = VTS_BSTR VTS_I4 VTS_VARIANT VTS_VARIANT;
CString propertyName = _T("Email Marking");
outlookUser->InvokeHelper(0x66, DISPATCH_METHOD, VT_DISPATCH, (void*)&userProp1, params, propertyName, 1); //falls here!
COleDispatchDriver* outlookUserProp = new COleDispatchDriver(userProp1);
static BYTE params2[] = VTS_VARIANT;
VARIANT va1;
va1.vt = VT_BSTR;
va1.bstrVal = emailMarking.AllocSysString();
outlookUserProp->InvokeHelper(0x0, DISPATCH_PROPERTYPUT, VT_EMPTY, NULL, params2, &va1);
delete(outlookUserProp);
Where I have added "//falls here!" is where it fails, and I think this is parameter issue, again. I cannot tell you what the error message I am getting because all that VS2010 is giving me is unhandled exception.
Looking at MSDN for VBA - http://msdn.microsoft.com/en-us/library/microsoft.office.interop.outlook.userproperties.add.aspx#Y19 - it is final two parameters to me that Outlook is expecting, add to folders and display format. What I am trying to achieve is to ensure that the add to folder is set to false, and for the final one, I would like to set this to text if possible. How can set theses in MFC? What is the correct syntax? Do they need to set in this way or could Outlook set theses with the parameters being passed?
Thanks
|
|
|
|
|
Member 2972992 wrote: CString propertyName = _T("Email
Marking");
outlookUser->InvokeHelper(0x66, DISPATCH_METHOD, VT_DISPATCH,
(void*)&userProp1, params, propertyName, 1); //falls here!
Using a CString object is probably what is causing you grief.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
No, I think - tatic BYTE params[] = VTS_BSTR VTS_I4 VTS_VARIANT VTS_VARIANT; is correct because I have seen this in http://repositorium.googlecode.com/svn/trunk/AbstractSpoon/OutlookImpExp/Source/msoutl.cpp
What should CString be?
|
|
|
|
|
Member 2972992 wrote: What should CString be?
Without actually trying it, I honestly do not know. I'd try VARIANT and BSTR to see what they produce.
Since InvokeHelper() throws an exception, why are you not catching it and examining the actual cause?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
I would hazard a guess from the code that its the same issue you had before, regarding the passing of [in, optional] VARIANT parameters. Everytime you come across an [in, optional] VARIANT parameter, what you have to pass is the address of a VARAIANT that contains type VT_ERROR, and value DISP_E_PARAMNOTFOUND. In this case, from the static BYTE params[] declaration there are two "optional" parameters.
COleVariant varOptional((long)DISP_E_PARAMNOTFOUND, VT_ERROR);
LPDISPATCH userProp1;
static BYTE params[] = VTS_BSTR VTS_I4 VTS_VARIANT VTS_VARIANT;
CString propertyName = _T("Email Marking");
outlookUser->InvokeHelper(0x66, DISPATCH_METHOD, VT_DISPATCH, (void*)&userProp1, params, (LPCTSTR)propertyName, 1, &varOptional, &varOptional);
Notes:
I have not looked up what dispatch method 0x66 is so I am not 100% sure.
The presence of a VTS_VARIANT in the params array does not always mean optional, however an optional parameter is always
The VTS_BSTR in the params array of an InvokeHelper call is expected to be an LPCTSTR. to allow the CString to pass the correct value always type cast it to (LPCTSTR). The type casting is neccessary because InvokeHelper is declared as void AFX_CDECL InvokeHelper(DISPID dwDispID, WORD wFlags, VARTYPE vtRet, void* pvRet, const BYTE* pbParamInfo, ...); so the compiler doesnt know specifically what to pass. By type casting it you ensure the correct value is passed.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
