|
Alvaro Mendez wrote:
I don't know where you get this: there are dozens of com calls to construct each CString required in the format function. Did you actually step through the CString or bstr_t code? And even if all those calls are being made, like you say, so what? Are they really slow?
Hello Alvaro, thank you for the suggestions. What I meant by the dozens of COM calls was that I have to call the COM object which is an interface to an accounting program 12 (or more) times to retreive a complete dataset to use in my SQL append query. This means that I would need (using the current method) to call the CString constructor 12 times to construct one SQL statement. I didn't mean that COM had anything to do with CString itself.
It isn't in fact slow at all, the bottleneck is in the database update, not reading the data from the COM component and building the SQL query, that's just my "old school" programming subconscious(circa 8088 Assembler)that screams loudly when a single bit is left on the table.
|
|
|
|
|
I've been trying to find any documentation to see if there is a message, event or notification from any Win32 API that indicates that the volume on your pc has changed.
I've found things close in the MCI, DirectX sections of the API but so far no luck.
Anybody have any ideas where this might exists?
|
|
|
|
|
There is, look up the Windows Multimedia SDK in MSDN. Key API calls here are mixerOpen, mixerClose and the struct MIXERCAPS. Have a look at the VC++ sample mixapp - %programfiles%\Microsoft Visual Studio\MSDN\2001OCT\1033\SAMPLES\VC98\sdk\graphics\audio\mixapp on my machine; it's all done with the Win32 API, not an OO wrapper.
Dylan
"In meetings, the person who is least competent usually does the most talking. Talking is a direct substitute for competence, at least in the minds of other people. Five minutes after you leave a meeting, you won't remember what anyone said but you will remember who did most of the talking. Withing a day your mind will translate that into a notion that the talker was unusually knowledgeable" - Scott Adams, Dilbert and the way of the weasel
|
|
|
|
|
how to map a drive programatically ?
can any body tell ?
r00d0034@yahoo.com
|
|
|
|
|
Here's a quick and dirty way, which I believe will only work on NT/2000/XP:
WinExec("net use z: \\computer\\folder", SW_HIDE);
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
The official way appears to be via the NetUseAdd API, but it doesn't look as fun as my previous solution  .
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
how to disconnect it?
r00d0034@yahoo.com
|
|
|
|
|
hello @all,
maybe, i am to stupid, but i don´t know, what i have to do. I posted this question a few days ago and i got a lot of help (thanks) but i don´t know what´s wrong?
that`s my code:
HMENU menu;<br />
<br />
menu = LoadMenu(AfxGetApp()->m_hInstance, MAKEINTRESOURCE(IDR_MENU1));<br />
::SetMenu(*(AfxGetApp()->m_pMainWnd), menu);<br />
<br />
EnableMenuItem(menu, ID_EXTRAS_SERVICE, MF_GRAYED|MF_BYCOMMAND);
the problem is, that the EnableMenuItem(menu, ID_EXTRAS_SERVICE, MF_GRAYED|MF_BYCOMMAND) does not function.
what´s wrong?
thanks
sunny
|
|
|
|
|
1. Check the return value of EnableMenuItem.
2. You may need to call DrawMenuBar(AfxGetApp()->m_pMainWnd) to see the change.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
the return value of EnableMenuItem is O.
that means, it does not function, right?
thanks
sunny
|
|
|
|
|
According to MSDN, 0 means that the menu item was previously enabled (MF_ENABLED). So it's working fine. But for some reason you're not seeing the change. Did you try calling DrawMenuBar?
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Alvaro Mendez wrote:
Did you try calling DrawMenuBar?
Where must i use it in my code????
thanks
sunny
|
|
|
|
|
Well, never mind. The problem has to do with MFC's internal mechanism for menus, as Michael Dunn explains in his message.
I recommend you learn to use the MFC's mechanism instead of using the Menu API directly.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
I will try it. Thank you very much.
sunny ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Nothing, it is perfect!!!
add, to the constructor of the mainframe
m_bAutoMenuEnable = FALSE;
see msdn article on "CMenu::EnableMenuItem"
|
|
|
|
|
yes, you are right.....GREAT! THANKS. 
i have another question:
now everything is NOT grayed in my 'first' mainframe.
how can i change this? because i don´t find an CMenu oder HMENU object from my first mainframe!
thanks sunny
|
|
|
|
|
As the saying goes RTFM!!! I would suggest you read the FAQ that Michael posted.
Assuming you are in the CmainFrame
CMenu *pMenu = GetMenu();
pMenu->EnableMenuItem(ID_FILE_OPEN, MF_GRAYED|MF_BYCOMMAND);
But there are many different methods to achieve this.
As someone once said the solution to any problem is simple once you know the answer!
|
|
|
|
|
|
thank you very much, sounds cool.
sunny 
|
|
|
|
|
it works!!!!!!!!!!!!!!!!!
GREAT!!!!!!!!!!!!!
THANKS!!!!!!!!!!
|
|
|
|
|
This one is just kicking me hard......Maybe someone can help......I'm trying to get completely dynamic context menus to work.....What's strange is these approaches work in debug mode, but never work in release mode....The way it fails in release mode is that the menu is not displayed, and the result is always zero.
What gives?
The following snippettes work in debug mode, but NOT in release mode:
// snip #1
CMenu oMenu;
ASSERT( oMenu.CreatePopupMenu() );
// i have a collection of menu command items that I add to the
// dynamic menu here
//
CONTEXT_COMMANDS_ITER oMenuCommandsIter;
for ( oMenuCommandsIter = poCommands->begin();
oMenuCommandsIter != poCommands->end();
oMenuCommandsIter++ )
{
oMenu.AppendMenu( MF_STRING,
(*oMenuCommandsIter).first,
(*oMenuCommandsIter).second.c_str() );
}
ClientToScreen( &oPoint );
DWORD dwResult;
dwResult = oMenu.TrackPopupMenu( TPM_LEFTALIGN | TPM_RIGHTBUTTON |
TPM_NONOTIFY | TPM_RETURNCMD,
oPoint.x,
oPoint.y,
this );
// end snip #1
// snip #2
CMenu oMenu;
CMenu oPopup;
ASSERT( oMenu.CreateMenu() );
ASSERT( oPopup.CreatePopupMenu() );
oMenu.AppendMenu( MF_STRING, 0, "Ignored" );
oMenu.AppendMenu( MF_POPUP, (UINT)oPopup.m_hMenu, "Ignored" );
// i have a collection of menu command items that I add to the
// dynamic menu here
//
CONTEXT_COMMANDS_ITER oMenuCommandsIter;
for ( oMenuCommandsIter = poCommands->begin();
oMenuCommandsIter != poCommands->end();
oMenuCommandsIter++ )
{
oPopup.AppendMenu( MF_STRING,
(*oMenuCommandsIter).first,
(*oMenuCommandsIter).second.c_str() );
}
ClientToScreen( &oPoint );
DWORD dwResult;
dwResult = oPopup.TrackPopupMenu( TPM_LEFTALIGN | TPM_RIGHTBUTTON |
TPM_NONOTIFY | TPM_RETURNCMD,
oPoint.x,
oPoint.y,
this );
// end snip #2
The following approach works in debug and release mode, but I don't like it because it creates a dependancy on the resource fork.
CMenu oMenu;
VERIFY( oMenu.LoadMenu( IDR_MENU_HIGHLIGHTS ) );
CMenu* poPopup = oMenu.GetSubMenu( 0 );
ASSERT( poPopup != NULL );
int iCount = poPopup->GetMenuItemCount();
// since I loaded a menu from a resource, throw all the stuff away
// i don't want/need here
//
for ( int iLoop = 0; iLoop < iCount; iLoop++ )
{
poPopup->RemoveMenu( iLoop, MF_BYPOSITION );
}
// add the commands I want on the menu
//
CONTEXT_COMMANDS_ITER oMenuCommandsIter;
for ( oMenuCommandsIter = poCommands->begin();
oMenuCommandsIter != poCommands->end();
oMenuCommandsIter++ )
{
poPopup->AppendMenu( MF_STRING,
(*oMenuCommandsIter).first,
(*oMenuCommandsIter).second.c_str() );
}
ClientToScreen( &oPoint );
DWORD dwResult;
dwResult = poPopup->TrackPopupMenu( TPM_LEFTALIGN | TPM_RIGHTBUTTON |
TPM_NONOTIFY | TPM_RETURNCMD,
oPoint.x,
oPoint.y,
this );
ASSERT( oMenu.DestroyMenu() );
I've even tried to go so far as to use CreateMenuIndirect() from a memory template, which just seems like too much for what I'm trying to do...
Anyone have any hints for me?
Just trying to keep the forces of entropy at bay
|
|
|
|
|
Just in case anyone is at all curious...here is the fix. The trouble seems to be that even though a popup menu is created, it must be stored in a containing menu object, and then refetched from that container.....very wierd.....
// first create the popup menu
//
CMenu oPopup;
VERIFY( oPopup.CreatePopupMenu() );
// now add all the commands to it from the command/prompt list
//
CONTEXT_COMMANDS_ITER oMenuCommandsIter;
for ( oMenuCommandsIter = poCommands->begin();
oMenuCommandsIter != poCommands->end();
oMenuCommandsIter++ )
{
oPopup.AppendMenu( MF_STRING,
(*oMenuCommandsIter).first,
(*oMenuCommandsIter).second.c_str() );
}
// create the container menu and insert the popup into it
//
// see: MSDN: Q75254
// PRB: TrackPopupMenu() on LoadMenuIndirect() Menu Causes UAE
//
CMenu oMenu;
VERIFY( oMenu.CreateMenu() );
oMenu.InsertMenu( 0, MF_POPUP, (UINT)oPopup.m_hMenu, "Ignored" );
// now have to pull the popup menu back out of the containing menu
// I know its strange, but this is how it works......
//
CMenu* poPopup = oMenu.GetSubMenu( 0 );
ASSERT( poPopup != NULL );
ClientToScreen( &oPoint );
DWORD dwResult = poPopup->TrackPopupMenu( TPM_LEFTALIGN | TPM_RIGHTBUTTON |
TPM_NONOTIFY | TPM_RETURNCMD,
oPoint.x,
oPoint.y,
this );
ASSERT( oMenu.DestroyMenu() );
ASSERT( oPopup.DestroyMenu() );
Just trying to keep the forces of entropy at bay
|
|
|
|
|
Hello, didn't read it too closely, but I think your looking at the wrong area for the problem completely:
In snip 1 there is a problem with your ASSERT statement. In a release build the ASSERT statement is going to translate to nothing so CreatePopupMenu will never get called.
ASSERTs are only compiled into the executable in a debug build.
VERIFY on the other hand which you used in the final example *is* compiled into the release code and will do the check but if it's a release version it will never report an error as it only reports an error in debug builds.
This means that any code inside an ASSERT is basically gone when you do a release build, any code inside a VERIFY is still there and will execute but will not report an error no matter what the result of the check.
What you should do instead of this:
RedZenBird wrote:
CMenu oMenu;
ASSERT( oMenu.CreatePopupMenu() );
Is something like this:
CMenu oMenu;<br />
BOOL BResult=FALSE;<br />
BResult=oMenu.CreatePopupMenu();<br />
ASSERT(BResult);
That way your function executes debug or release.
If it was release code and you thought there was any chance of that function failing you would want to add some form of error handling based on the BResult status after calling CreatePopupMenu().
|
|
|
|
|
You are right...So, I was driving the train all around the mountain and not even seeing the track in front of me.....gads!!!!
Once again proving: "Preoccupation clouds the mind" .....
Thank you for the feedback nonetheless
Just trying to keep the forces of entropy at bay
|
|
|
|
|
I know I've seen it some place, but can't remember...
How do you change the starting index value? It defaults as 0 to x, I'd like to use something like 3 to x.
Thanks for any help or direction.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
