|
|
look at following code:
STDMETHODIMP CADOTier::OpenRecordset(VARIANT query)
{
VARIANT v;
V_VT(&v) = VT_DISPATCH;
V_DISPATCH(&v) = (IDispatch*) m_connection;
// Need the AddRef() as VariantClear() calls Release(), unless fAddRef
// false indicates we're taking ownership
//
V_DISPATCH(&v)->AddRef();
return m_recordset->Open(query, v, adOpenDynamic, adLockOptimistic, adCmdText);
}
It is a method Implementation of a COM object. It uses another COM object method "open" to open a recordset with a parameter of IDispatch interface type passed--v.
But who can tell me why I must call V_DISPATCH(&v)->AddRef() to increase reference count and where the reference count will decreased?
(VariantClear ? But not find here)
TKS
|
|
|
|
|
I have an array, containing a CStringList and another CArray. Is there an easy way to copy a CStringList or another CArray short of manually iterating through each element, copying it over each time???
// in .cpp file somewhere...
CArray <ctable, ctable&="">* m_parrTables;
// in .h file
class CTable : public CObject
{
public:
CString m_strTable;
CStringList m_lstParents;
BOOL m_bProcessed;
CArray <crule, crule&="">* m_parrRules;
CTable& operator=(const CTable& a)
{
m_strTable = a.m_strTable;
m_lstParents = a.m_lstParents; // ?????
m_bProcessed = a.m_bProcessed;
m_parrRules = a.m_parrRules; // ?????
return *this;
}
}
|
|
|
|
|
A CStringList is exactly that: a list. As a result, there is no way of copying the elements apart from iterating through them.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I want to change the text that the clock displays. I've subclassed the window and intercepted the WM_SETTEXT message, but it only changes the windows text in Spy ++, not the displayed text.  How do I do this?
Greg J. Hedlund
SuperStar
|
|
|
|
|
I am using this function to get the serial number of a hard drive. However, it doesn't work when running under Win 9x and trying to get the serial no. of an NTFS partition (e.g. Win 9x workstation trying to get serial no. of NT server partition). It always returns 0. Is there any way around this?
|
|
|
|
|
I want my application which is written with VC to support Multiple language. i did the follow:
first, i put resource to dlls, each dll is for one language,
then,
CMyApp::InitInstance()
{
int nLang = detect_which_language_to_use();
CString strLang;
strLang.Format("Lang%d.dll", nLang);
//load the resource
HINSTANCE hInstance = ::LoadLibrary(LPCTSTR(strLang));
ASSERT(hInstance);
::AfxSetResourceHandle(hInstance);
}
it works. but now i want to let the user choose the language, that is, i add a menu in my program, user can choose the language he want by clicking the menu.
how can i do these? thanks.
hs
|
|
|
|
|
Hello, the codegurus around the world. 
Before you make the multi-language application, you had better consider the followings.
For example,
1) English Windows 9x can't show Japanese corretly.
2) Some Japanese user can't understand English.
So, what language will you use for the menu item? English??
At the menu, we can use CDialog class with the radio button something like that
for the user to select the language....
But before that, you must solve some problems.... 
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
i change the resource(AfxSetResourceHandle) by clicking a menu item, then i show new a dialog,my program use the dialog accord to my choice, but the GUIs which had been showed was not effected.
|
|
|
|
|
Hello, the codegurus around the world.
Actually, I don't understand your problem very well,
but if I guess....
After the code passes the point of AfxSetResourceHandle, the application can't change
the resouce DLL. (However, we may use FindResouce API function for each resouce ID..?)
So, before AfxResourceHandle is called, we must choose which resouce DLL will be used.
As a result,
CMyDialog dlg (AfxGetMainWnd()); // for the bug of Windows ME.
dlg.DoModal(); // with the radio button ?
// Get the data which the user selects as the language from the dialog;
if (sLang == EN)...
HINSTANCE hInst = Loadlibrary (someDLL);
if (hInst)
AfxResourceHandle(hInst);
......
// After this, we can't change resouce DLL.
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
