|
That's right, it's not him but her 
Well,I cant use that API (SHGetSpecialFolderPath) as it says 'If a virtual folder is specified, this function will fail' n RecycleBin is the virtual folder...Actaully not even folder, it's a file....I will look into it. Thanks to U all for giving the direction.
Bye
Supriya Tonape
-- modified at 2:48 Saturday 8th October, 2005
|
|
|
|
|
The following code:
int i = 0;
cout << i++ << i;
why does it output 00?
|
|
|
|
|
because i++ is the post-incrementation, which mean that the incrementation is done at the end of the expression (here cout << i++ << i;).
by opposite,
cout << ++i << i; would have outputed 11 and
cout << i << ++i; would have outputed 01.
is that all clear ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
|
I am sure this will catch someone out there, me included.
The end result will be machine specific, ie. undefined. I guess it is because different machine will prioritise ++ and << in different manner.
|
|
|
|
|
operators priority are not system dependant.
the priority is defined by the compiler, and specified in the standard of C++ !!!
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
...and I please the one who voted me down to explain his choice... 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Laffis wrote:
why does it output 00?
Because it just happened to. "Sequence points" are those placecs at the end of statements, full expressions, before a function is invoked, and right after it returns. In between sequence points, side-effects of operators may not have taken place, and values are indeterminate. The exact point at which that increment takes place is unknown and unspecified; only the sequence-point semantics need to be satisfied. This allows compilers to either increment in-place after makng a copy or make an incremented copy which does not have to be set until the value is next needed, which by definition is after the sequence point.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hmmmm, pretty good! mate...Beer beer...
|
|
|
|
|
Hi,
Is there any way to clear the contents in CDC of a client window ?
I have a transparent image in my CDC, and before drawing the next image, I would like to clear and reset the DC.
Thanks
Jugs
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
Use the Invalidate(true)
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
|
Hi,
Thanks for the reply.
I want to clear the CDC from inside OnPaint(). Calling Invalidate( ) of CWnd will again invoke the OnPaint. I am getting a DC inside OnPaint which contains an already painted image, which I would like to remove. I would like to draw a new Transparent image, But since the previous image is already there and the new image is transparent, I am having problems.
Thanks
Jugs
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
Is your background simple enough that you could just fill it with a background color?
<br />
pDC->FillSolidRect(rect, RGB(255,0,0));<br />
"When you know you're going to eat crow, it's best to eat it while it's still warm." - Reader's Digest
|
|
|
|
|
I have now successfully pinted by
using a CScrollView , now i am geting
a problem that he font size is very
small on the pritn-out , but actual
size in the display is fine visible.
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
You need to compensate for the printer DPI versus the screen DPI. You do this by reading the device caps and scaling the font to get the correct size.
|
|
|
|
|
vikas amin wrote:
a problem that he font size is very
small on the pritn-out , but actual
size in the display is fine visib
use CFont::CreatePointFont().. if you need 11 pt font then pass 11*10=110 value in this variable before printing 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
VC6
Win2K
I have a main menu with the following arrangement
<br />
File<br />
---Select Folder<br />
---Configure<br />
---Exit<br />
Start<br />
Stop<br />
Pause<br />
Resume<br />
I'm trying want the Stop, Pause and Resume items to grey out when they're disabled, but the methods I've tried in order to accomplish this have all failed in one way or another.
Calling pCmdUI->Enable(FALSE); in the update handler will disable the menu item, but it won't gray out.
If I use the following code, the menu item will gray out only after the user tries to click on it, and then, it doesn't un-gray unless it's allowed to AND the user clicks on it again.
BOOL bEnable = (m_bShowRunning && !m_bShowPaused);
DWORD dwFlags = (bEnable) ? MF_BYCOMMAND | MF_ENABLED
: MF_BYCOMMAND | MF_DISABLED | MF_GRAYED;
CMenu* pMenu = GetMenu();
pMenu->EnableMenuItem(ID_SHOW_PAUSE, dwFlags);
Does anyone have any helpful ideas?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
-- modified at 8:11 Friday 7th October, 2005
|
|
|
|
|
John Simmons / outlaw programmer wrote:
Calling pCmdUI->Enable(FALSE); in the update handler will disable the menu item, but it won't gray out.
Then something else is wrong. I just had a look at several of my SDI applications, and if pCmdUI->Enable(FALSE) were used on any of the menu items, it was definitely grayed out. Perhaps your definition of "gray out" is different than mine.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
Then something else is wrong.
Ummm, yeah, that one didn't get by me, hence my original message...
DavidCrow wrote:
I just had a look at several of my SDI applications, and if pCmdUI->Enable(FALSE) were used on any of the menu items, it was definitely grayed out.
Well that doesn't answer my question...
DavidCrow wrote:
Perhaps your definition of "gray out" is different than mine.
I seriously doubt that. Like I said, it *will* gray out when the user clicks it.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote:
Well that doesn't answer my question...
It should have indicated to you that pCmdUI->Enable(FALSE) is the way to do this in MFC. For it not to work is a good indication that you are doing something wrong elsewhere. Trying to do this with that EnableMenuItem() and GetMenu() code is like sanding against the grain.
John Simmons / outlaw programmer wrote:
I seriously doubt that.
I don't. Unless you are messing around with colors, a menu item that is gray is synonomous with one that disabled. In other words, I've not seen an enabled menu item that was gray, nor have I seen a disabled menu item that was non-gray.
Have you considered creating a temporary SDI project that does nothing but alter menu items via the ON_UPDATE_COMMAND_UI() handler? That would help to eliminate other code that might be masking the real problem.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-- modified at 9:52 Friday 7th October, 2005
|
|
|
|
|
It already is a SDI app, and no, I'm not messing with colors. Like I've already said twice, it grays out only AFTER the user clicks it.
I've even tried simply doing this on the updateUI handler:
pCmdUI->Enable(FALSE);
...and that still doesn't gray it out. This is all MFC with no derived classes regarding the menus, and all handlers were added through the class wizard, so I'm not doing anything strange at all.
I think it's got something to do with the fact that the menu is the main menu and not a sub menu (again, something I've already mentioned). I saw something somwhere that said the state of a menu items is updated before the menu is drawn. I'm thinking that since it's the main menu, and only drawn once (or when the window is resized?), it doesn't know about the disabled state because that's not checked until after the menu is drawn.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Try this instead:
DWORD dwFlags = (bEnable) ? MF_BYPOSITION | MF_ENABLED
: MF_BYPOSITION | MF_DISABLED | MF_GRAYED;
pMenu->EnableMenuItem(1 or 2 or 3 or 4, dwFlags);Another idea would be to create a different menu hierarchy where Start, Stop, Pause, and Resume are all under a common menu item.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Deleted the menu items and created a toolbar. The updateUI stuff works on the buttons. I think it goes back to the fact that I'm playing with the mainmenu instead of a sub-menu...
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
|
Hello guys,
I have next strange situation :
I have a function
CString Add(CString var1,CString var2)
{
..
}
which i use for adding two huge integers.
then for example I declare two variables :
CString x = "457235872349857348957238945723894579234896234789563";
CString y = "573489573894573894579234852378456782345683475683746";
then add them , for example 1000 times
while()
{
..
Add(x,y);
..
}
It takes my computer aproximately 5 seconds to do these calculations.
But then i decided to modify the Add function like this :
CString Add(CString & var1,CString & var2)
{
..
}
I expected that the calculations would be faster as no copy objects would be created in this case inside Add function , as I was passing directly addresses.
But the result is opposite
Can anybody explain why ??
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
