|
|
Hi,
I assume in your code you instantiated a CSnp object and added a pointer to it to the Snaplist. The Snaplist just contains the pointer, calling removeAt on it will remove the pointer but not the allocated memory that it points to. So yes you will need to manually call delete on it! Or else you will get a memory leak.
|
|
|
|
|
It's syntax that we have to put '&' right before pointer to member function.
For example here.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};
int main(){
fpop pFunc;
pFunc = &Test::Op1;
return 0;
}
However, when I take a look at ON_COMMAND(or any other messages) in MFC, it seems a bit different from what I think is right.
VS6.0 is okay. It follows the right syntax as you see below.
You can clearly see & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },
But in VS2008, it goes a bit weird. There is no & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \
static_cast<AFX_PMSG> (memberFxn) },
Moreover, in spite of the fact that there is no & before memberFxn,
each line below works perfectly.
1. ON_COMMAND(ID_APP_ABOUT, CSingleApp::OnAppAbout) // &
2. ON_COMMAND(ID_APP_ABOUT, &CSingleApp::OnAppAbout) // no &
I tried to find why, and I was curious if it could be because of static_cast<> but it turned out that static_cast has nothing to do with it.
So I am wondering why in VS2008 I have 2 choices where I put & or I don't have to put &.
|
|
|
|
|
It goes waaaay back to the original C language of the 1970's. In the first edition of "The C Programming Language",
Kernighan and Ritchie wrote: ... an identifier which is declared "function returning ...", when used except in the function-name position of a call, is converted to "pointer to function returning ...".
In the second edition, the wording has changed to
... and expression of type "function returning T," except when used as the operand of the & operator, is converted to "pointer to function returning T."
In other words, the & has always been optional.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
First of all, Thanks you so much for answering my question.
However,
I think that case that you mentioned is about just "pointer to function."
Peter_in_2780 wrote: the & has always been optional.
But when using "pointer to MEMBER function", the & is not optional, but necessary as you see below.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};
int main(){
fpop pFunc;
pFunc = Test::Op1; return 0;
}
I know that MFC's message pump consists of Pointer to member function, which needs the &.
Could you explain why?
Thanks.
|
|
|
|
|
Digging a bit deeper, I came across this[^] right here on CP. Seems VC6 and VC7 break the rules as you noticed... See just after the second code block below the heading "Member Function Pointers".
Way too much information in that article for me! But if I ever need to go there...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
That looks like a great article... Looks like I have some reading ahead of me...
|
|
|
|
|
It's a simple problem.
At First, the massage map is implemented by an array with a structure.
Secondly, the syntax error is actually a kind of warning.
Third and finally, The massage map function starts with disabling the warning by a macro PTM_WARNING_DISABLE
So, you may assign the function to a pointer without reference operator &.
Here is an example,
PTM_WARNING_DISABLE
fpop pFunc[1] = {Test::Op1};
PTM_WARNING_RESTORE
However, an interest problem occurs when you call the function with the function pointer.
And the problem is all yours.
modified on Wednesday, August 31, 2011 5:42 AM
|
|
|
|
|
did you mean to send this message to the OP? ...because I didn't ask the question...
|
|
|
|
|
Hi,
GetCharABCWidthsFloat returns different values on XP, Vista and Windows 7. How can I solve this problem?
Is there a workaround method to handle this?
Best,
|
|
|
|
|
The size of characters can depend on a lot of things, how the given system renders the fonts, the DPI settings, what font you use of course, display drivers probably, and who knows what else. I supose the GetCharABCWidthsFloat is made to give the sizes based on the current "configuration", which is probalby not the exact same on those systems. Why is that a problem for you?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I used same "configuration." GetCharABCWidthsFloat returns different values on XP, Vista and Windows.
You can have a test run. You will see it.
Is there any GDI function call can do the same job?
Thanks,
|
|
|
|
|
Just have a test run, you will see it. It will be a problem for you also.
Thanks
|
|
|
|
|
I don't doubt that it returns different sizes, i don't understand why you say it is a problem. I don't see the documentation stating that it will return the very same values "everywhere", it might return different values on the same operating system in different DPI settings. It is kind of like saying that GetVersionEx has a problem because it returns different values under different operating systems.
Or i am completely missing your point here...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Yes, you completely miss my point here.
Forget it.
|
|
|
|
|
First off, I agree with Code-o-mat. Actually the function isn't the problem here. It does exactly what it is supposed to do, namely (from MSDN): "[..] retrieves the widths, in logical units, of consecutive characters in a specified range from the current font."
Now this value logically varies with different fonts, but also with different settings and different draw APIs.
So what exactly is the problem you are having? You only say that you think the function is supposed to work differently. What do you think it should do then? That's where your problem lies: the function and what you are expecting of it are not in tandem.
|
|
|
|
|
"You only say that you think the function is supposed to work differently."
I did not say "I think". I actually tried the function and got the results. I tried on different machine (XP, VISTA, WIN 7). I used exact same configuration. But I got different results.
Thank you for your time to answer the question.
If you want to know what I mean you might need to try this function call on different machine. Then you will get what I got.
My question is very simple "GetCharABCWidthsFloat returns different values on XP, Vista and Windows 7, why?". You guy make it complicate.
Best,
|
|
|
|
|
Maybe this[^]link will help?
|
|
|
|
|
Thank you for the link. I found the link before I post my question.
I am thinking is there a workaround method instead of changing the Windows' setting.
It looks like it is only solution. MS should design a new function call like GetCharABCWidthsFloatEx to allow user to specify it is a standard or ClearType font and with a default value "standard".
Best,
|
|
|
|
|
transoft wrote: I did not say "I think". I actually tried the function and got the results. I
tried on different machine (XP, VISTA, WIN 7). I used exact same configuration.
But I got different results.
But it's not the same configuration - it's a different platform and there is no way it can be the same video drivers. Windows is constantly changing how text is drawn. ClearType, NTDDI, and changes to the fonts themselves mean that there might be different values.
Are we talking about large differences in the return values?
Maybe as a test, you can write a string, and measure the bounding rectangle and see if it's different on each platform.
/* Charles Oppermann */
http://weblogs.asp.net/chuckop
|
|
|
|
|
I saw this question about a minute after you posted it. Having never heard of the function before I started looking into it, finding as others have mentioned that the values are supposed to depend on a number of different things.
Immediately, I set to work whipping up an application to test the function. No matter what I thought of to try,I couldn't get the vales returned to change. I ran the app both under XP 32 bit and Win7 64 bit. Each OS returned the same values, as did each font I tried (only tried 2) as did each font-size and weight I tried. Win7 has clear-type enabled, XP doesn't. Win7 running on my laptop, XP running in a virtual machine on the same laptop.
This made it clear to me that I wasn't qualified to even begin to answer your question. Though, still I couldn't help wondering why it was such a problem. Surely different conditions would mean that the mapping between logical width and number of pixels would change.
Take for example, the dialog units that are used. (on dialogs, oddly enough) These vary based upon the size of the chosen dialog font. This allows an app to continue to look right whether your default text size is 11pt and you use it as a desktop 1 foot in front of you, or if you have text-size set to 30pt and you use it as a media-pc, hooked up to your telly. This is one of the differences between regular windows and media-center edition - the default text size.
I would suggest that you mention why it matters to you if the function returns different values. There is after all, a transformation that happens to these values before they are ultimately used, so why can't you also do this transformation before you do your calculations?
The clearer you make your problem, the more likely you are to get a solution that's a good fit!
|
|
|
|
|
Thank you so much for spending so much time on this. I really appreciate it.
Actually, I have a solution (Don't use clear-type font) for it now. The reason I post my question here is that I want to find a workaround for this. I hate to change Windows setting every time when I start to use my software. Right now it looks like it is impossible without changing Windows setting.
Best regards,
|
|
|
|
|
my control loads fine some methods work
void CWindowsGTView::OnInitialUpdate()
{
CHtmlView::OnInitialUpdate();
SetWidth(300);
SetHeight(300);
MessageBox(L"test");
GetDocument()->SetTitle(L"one mad scientist");
Navigate2(_T("http://localhost/test_build.php"),NULL,NULL);
}
although set SetTitle and some methods work other don't work
and don't show up in intellesence either
//for example this doesn't work but SetTitle does
GetDocument()->InvokeScript("test");
http://msdn.microsoft.com/en-us/library/aa752046%28v=vs.85%29.aspx[^]
basically trying to do this to allow two way communication
heard some reports this is broken in windows7 and ie 9
but nothing substantial
have not used mfc a lot used to the native api but
word around is com is a real head ache in the native api
so far this is more of a head ache, if anybody has done this sort of thing and point out where im going wrong be much appreciated!
|
|
|
|
|
Hi,
suppose if i declare any virtual function as an inline how it differentiates from compile time ?
Base class object pointer variable may reference to inherited object.How inline works in such case?
thank you
modified on Thursday, August 25, 2011 9:24 AM
|
|
|
|
|
Since it can't it won't inline it (inline is just a tip for the compiler).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|