|
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
|
|
|
|
|
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.
|
|
|
|
|
One solution is to derive your own CComboBox.
Kuphryn
|
|
|
|
|
I thought there was an option to set the starting index...
|
|
|
|
|
Sendmessage(hwnd, CB_SETCURSEL ...) should do it in Win32. I don't remember which PARAM is the the index value but a search on MSDN should help you out.
|
|
|
|