|
actually masaaki you could put a menu of bitmaps of flags to select the language you wanted as they do on many web sites
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hello, the codegurus around the world.
lauren:
I am already working for the other part of bitmaps for the international language.
However, if we use the international language by bitmap format,
we had better be careful about the appearance of this.
For example, like the menu,
1) Japanese (normal letter on Dialog) - (Japanese) by bitmap.
This bitmap had better have the same color of the background like the dialog
as well as the same size of the font as the normal letter of dialog.
As a result, we work more than we expect ....
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
I began writing a program on one of my computers the other day, and I decided to work on it on different computer later on...I zipped the source code files, and moved them to my other computer...now that I have unzipped them, and resumed working on my program, I have no problems compiling, or anything like that, but instead the menu that pops up when trying to access a function with the dot operator will not show. Any ideas? When I use the -> operator, a menu comes up, but not with the . operator.
Thanks again.
|
|
|
|
|
Get Visual Assist. ( www.wholetomato.com ). Not an immediate answer to your question, but VA extends these menus, autocompletes, case corrects, etc, etc, etc. It rules.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Apparently my compiler (it's VC6.0) has decided that try and the following catch block are not needed in release mode, and I have not the slightest clue as to why. For example, if I create a new dialog app and put this code in it:
void CJunkDlg::OnButton1()
{
char *p = 0;
try
{ *p = '\0'; }
catch(...){ AfxMessageBox("!"); }
}
and compile in debug.. click.. "!". That's expected behavior!
Rebuild it in release and I get an access violation as if the try/catch wasn't there.
I've checked the compiler settings. I have /GX. That's the default for a new project after all!
If I put the warning level on 4 and rebuild, I get the warning C4702: unreachable code when in release, and nothing in debug. If I disable optimizations in release, the warnings evaporate and the catch(...) works as advertised. For obvious reasons, that's not the solution I'm looking for.
Here's a snippet of the assembly generated in release with full optimization (it looks bizarre to me):
00401494 nop
00401495 nop
00401496 nop
00401497 nop
00401498 nop
00401499 nop
0040149A nop
0040149B nop
0040149C nop
0040149D nop
0040149E nop
0040149F nop
004014A0 mov byte ptr ds:[0],0 <<< *p = '\0';
004014A7 ret
004014A8 nop
004014A9 nop
004014AA nop
004014AB nop
004014AC nop
004014AD nop
004014AE nop
004014AF nop
What's with all the nop's?
I really hope someone out there has seen this before. Thanks much if you can help!
Matt
|
|
|
|
|
Interesting stuff - the compiler seems to be changing the call format of the function, optimizing away the stack operations, which disables the exception framework.
I made a small change to your code, and added optimization pragmas - this works now in release:
#pragma optimize( "", off )
void CAboutDlg::OnButton1()
{
try
{
_asm int 5;
}
catch(...)
{
AfxMessageBox("!");
}
}
#pragma optimize( "", on )
I agree with you that the compiler is being a bit aggressive with its optimizations. I can understand the compiler removing code like int x=0; if x is not referenced again, but not this.
In looking at the dissassembly you'll see that the compiler is removing the stack overhead - thats why we get such a minimal asm output - and also why the try catch is ignored - if there's no stack entry/exit, there's no room for the exception framework.
Here's the dissassembly window in release without the pragmas:
163: void CAboutDlg::OnButton1()
164: {
004016A0 int 5
165:
166:
167: try
168: {
169: _asm int 5;
170: }
171: catch(...)
172: {
173: AfxMessageBox("!");
174: }
175:
176:
177: }
004016A2 ret
Contrast this with the code generated with #pragma optimize( "", off ) :
163: void CAboutDlg::OnButton1()
164: {
004016A0 push ebp
004016A1 mov ebp,esp
004016A3 push 0FFh
004016A5 push offset $L77634 (00402180)
004016AA mov eax,fs:[00000000]
004016B0 push eax
004016B1 mov dword ptr fs:[0],esp
004016B8 push ecx
004016B9 push ecx
004016BA push ebx
004016BB push esi
004016BC push edi
004016BD mov dword ptr [ebp-10h],esp
004016C0 mov dword ptr [ebp-14h],ecx
165:
166:
167: try
168: {
004016C3 mov dword ptr [ebp-4],0
169: _asm int 5;
004016CA int 5
170: }
171: catch(...)
004016CC jmp $L77388 (004016e2)
172: {
173: AfxMessageBox("!");
004016CE push 0
004016D0 push 0
004016D2 push offset string "!" (00405070)
004016D7 call AfxMessageBox (00401cfc)
174: }
004016DC mov eax,offset $L77388 (004016e2)
004016E1 ret
175:
176:
177: }
004016E2 mov dword ptr [ebp-4],0FFFFFFFFh
004016E9 mov ecx,dword ptr [ebp-0Ch]
004016EC mov dword ptr fs:[0],ecx
004016F3 pop edi
004016F4 pop esi
004016F5 pop ebx
004016F6 mov esp,ebp
004016F8 pop ebp
004016F9 ret
Note the jmp $L77388 - this is where the exception framework takes over.
As for the nops, it may be that you have incremental linking enabled, and the compiler is just reserving space in the obj file so that the call can be recompiled in place. (Shouldn't have incremental on in release though).
So, is this a bug or a feature? I think I've been assimilated to the point where I'm too tired to argue - but it would be nice to have some better warnings - unreachable code ain't that bad, though - maybe should show at level 3.
|
|
|
|
|
Interesting stuff - the compiler seems to be changing the call format of the function, optimizing away the stack operations, which disables the exception framework.
I forgot the other side of the coin - since catch(...) is technically only for catching C++ exceptions/objects, the compiler has the right to get rid of the try/catch block here if it can see that no C++ exception can be thrown, which is true - the access violations in our codes are processor traps.
What's murky is how and why these traps _are_ translated and passed to our apps in such a way that a catch(...) handler will catch them - I think it was a decision made long ago and maintained for compatibility.
If this were written using windows Structured Exception Handling instead, the results might be different.
|
|
|
|
|
Thanks Tim!
Good to know about the pragma option, I hadn't seen that before.. but then again.. ouch, no optimization!
The thing I find most disturbing about it is how silent it is.. works great in debug.. then silently disappears in release. Very bad behavior IMO. The optimizer should issue a warning each and every time it throws away a block of functional code. Unused initializations are no big deal, 20 lines of code are quite another! I suppose I've just become one of those gluton for punishment error level 4 people.
I found that you can manually include the compile flag /EHa and this apparently will force the inclusion of all try/catch blocks regardless of whether any of the code will throw a c++ exception. Now that I've included the flag, the access violations are caught, but now I'm getting some other bizarre behavior I haven't been able to track down. If I can tie it to this, I'll be sure to follow up on this post.
Thanks again,
Matt
|
|
|
|
|
Ah.. well the /EH switch fills in some blanks - by using /EHa you are enabling asyncronous excepiton handlng, rather than the default of synchronous - thus telling the compiler that an exception can be thrown anytime, rather than just at a throw statement, as in /EHsc.
The /GX switch is said to be equivalent to /EHsc.
Be interesting to know what the strange behaviors are. Reading up on /EH helped me get little farther in understanding this stuff. The "Exception Handling: Default Synchronous Exception Model" topic in the MSDN is useful.
|
|
|
|
|
Well, the strange behavior was all my own.. wish I could say it wasn't! Pretty fun bug... created a recursing exception.
In my quest to handle the (...) case better, I explored the _set_se_translator function which allows you handle win32 exceptions, such as access violations, etc., by translating them into a c++ exceptions and throwing it. Exceedingly handy because you can then handle both c++ exceptions and Win32 SE's at once without using the (...) at all. By using this approach, you can identify everything about the SE, just as if you were using the __try/__catch approach. Very nice!
The only drawback to all this is that the handler table is created per thread, so, if you use multiple threads, you have to make sure you install the handler as the first step in every thread. This becomes especially fun when your code is called by someone else's multiple threads. (luckily, _set_se_translator returns the previous translator, so it can be saved and restored prior to return.) Small price to pay...
Matt
|
|
|
|
|
I have two questions I could really use some help with...first of all, what is the difference between the two following function calls?:
(1): m_cTabListMode.InsertItem(0, _T("Icon"));
(2): m_cTabListMode.InsertItem(0, "Icon");
What is the "_T()" thing for...?
Ok, second question. I'm working with a list control, and I need to display prices of particular items in one column of my listctrl. Below my list control I have an editbox which needs to contain the total price of all of the items in the listbox. As the listctrl requires that the prices be CString's, how do I convert them back to float's so that I can add up the total?
Help on either topic would be greatly appreciated!
-Cam Desautels
|
|
|
|
|
Float to CString:
mystring.Format("%.2f", myfloat);
CString to float
myfloat to atof(mystring);
I *believe* the _T makes the string Unicode ? It's something *like* that, and is certainly superfluous in my experience ( i.e. I've never needed to do it or broken anything by not doing it )
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Thank you, very, very much.
|
|
|
|
|
_T(x) is a macro that that makes a string literal Unicode compliant.
from TChar.h
#define _T(x) __T(x)
#define _TEXT(x) __T(x)
and elsewhere in TChar.h
#ifdef _UNICODE
...
#define __T(x) L ## x
...
#else
...
#define __T(x) x
...
#endif
so _T("Icon") becomes
"Icon" if _UNICODE is not defined,
and L"Icon" if _UNICODE is defined
So if you are not writing a Unicode app, there is no difference between the two function calls, but if you are using Unicode, there is a definite difference.
|
|
|
|
|
Another difference.
If you are writing a UNICODE application, it runs on NT/2000/XP only.
If you are writing an MBCS/SBCS application, it runs on all the operating systems,
and when run on NT/2000/XP the MBCS/SBCS application will run slower than the
UNICODE application because all MBCS/SBCS strings are converted to UNICODE
strings at the Win32 API boundary. Matt Pietrek wrote an article on this years ago.
So, Christian, for your Win NT/2000 applications, maybe you should make a UNICODE
build?
Slight Aside: If you are doing many multilanguage apps, there are so MBCS only bugs
out there which will bring the box to its knees (the debugger doesn't even get a chance).
Stephen Kellett
|
|
|
|
|
How can i export Constants from a VC Dll.Actually the constants used are defined within a header file that is included in this project !!
|
|
|
|
|
by constants i assume you mean #define whatever whatever
so you either include the header file throughout the project or copy the constants into the new project
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
I hope to know how to associate imagelist control to listview control version 6 in VC++.
I know how to do it in listview 5 by the macro. And i know how to do it in VB by the listview's property sheet.
But in VC++ i can't associate the imagelist 6 to listview 6 at design time. The dropdown list of the imagelist has only one item of NULL. And I don't know how to associate dynamically. For the wrapper class of listview6 has a function of SetSmallIcons(LPDISPATCH). But how can i get the LPDISPATCH from the wrapper class of imagelist?
My project uses a lot of list view 6. so if i change to list view 5, we need to revise a lot of code.
Thanks in Advance
Liu Jun
|
|
|
|
|
With your CListCtl call:
thumbListCtl.SetImageList(&thumbList, LVSIL_NORMAL);
where thumbList is of type CImageList
There's a tutorial around somewhere on how to do this... might be on CodeGuru. Do a search for "thumbnail". If you need more help I can send you the source to my function which loads from a database, but you should be able to work it out...
|
|
|
|
|
I have a dos program (like dos program).
I want to exec this program from visualc but i do not want that that dos_program shows a
its window.
thx.
|
|
|
|
|
use
ShellExecute(m_hWnd, "open", your_programs_name, parameters, defaul_folder, SW_HIDE);
Mustafa Demirhan
|
|
|
|
|
HI
Strange kind of class
Some times I see this class like below :
LINE 1 : class CImage;
LINE 2 : class CTestpicDlg : public CDialog
LINE 3 : {
LINE 4 : // Construction
LINE 5 : public:
LINE 6 : void draw();
LINE 7 : CImage *image;
LINE 8 : CTestpicDlg(CWnd* pParent = NULL); // standard constructor
LINE 9 : }
So my question is about two thing's :
1- (CImage)class ,it hasn't any braces and !!!
2- The (CImage)class defined in cimage.lib which I append it in my project
so why I must write LINE 1, if I omit this line I get alot of errors like :
error C2143: syntax error : missing ';' before '*'
error C2501: 'CImage' : missing storage-class or type specifiers
Thank you ...
AHMAD ALWASHALI
|
|
|
|
|
LINE 1: Class CImage; is a forward reference to another class that lets the CTestPicDlg class know what to do with the LINE 7: CImage *image ptr type ... excluding LINE 1: gives compile errors cos the compiler then doesnt know what CImage is
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Thank you lauren
but (CImage)class defined in cimage.lib which I append it in my project
can you tell me please
AHMAD ALWASHALI
|
|
|
|
|
The compiler can't know anything about classes inside .lib files, they are only used in the link phase. The CImage class must be declared in a source file (.cpp or .h) so that the compiler can see it.
|
|
|
|
|