|
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]
|
|
|
|
|
It is actually possible under certain conditions for the compiler to inline virtual functions.
Consider the following:
class Base
{
virtual void func() {...}
};
class Derived : public Base
{
virtual void func() {...}
};
Base b;
b.func();
Derived d;
d.func();
In both cases, the compiler can chose to inline func.
|
|
|
|
|
Yes, you are right, I should have written: "the compiler cannot always inline virtual functions...". However, the rationale behind virtual function is for supporting polymorphism, hence I assumed, in my answer, that late binding was the case of interest.
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]
|
|
|
|
|
There are two rather common examples where virtual functions are resolved statically, and therefore can be inlined without problem:
1. Explicitely calling the base class implementation
2. Virtual destructors. The compiler will automatically create a chain of calls to destructors according to the inheritance chain. These are resolved statically. The only thing that may be resolved dynamically (at runtime) is the top level call, and even that only if the compiler cannot determine the actual class at compile time
class Shape {
bool state;
public:
inline virtual void initialize() {
state = false;
}
inline virtual ~Shape() {}
};
class Square : public Shape {
float width;
public:
virtual void initialize() {
Shape::initialize();
width = 0.;
}
~inline virtual ~Square() {}
};
int main() {
Shape* pShape = new Square;
pShape->initialize;
delete pShape;
return 0;
}
|
|
|
|
|
You can inline virtual functions just like any others: either by using the 'inline' keyword, or just by writing the function definition right into the declaration. Sometimes this makes sense (such as for destructors), sometimes it doesn't. It mostly depends on whether or not a compiler is able to decide what class a particular object pointer actually points to. Somtimes this can only be detemined at runtime and in that case, obviously, no inlining will occur.
More information and examples can be found on the web, e. g. here: http://msdn.microsoft.com/en-us/magazine/cc301407.aspx[^] or here: http://drdobbs.com/cpp/184403747[^]
In short - if the type of an object pointer can only be determined at runtime, then inlining is not possible, even if the base class and all derived classes do have inlined implementations of that function. If you really, absolutely, desperately need a function to be inlined, either make sure that a particular version is being called (if that is even possible), or simply don't use inheritance for that. That said, since inlining is really only the very last step in performance optimization, it's usally not a real issue: if you can't inline, then you just don't.
|
|
|
|
|
How to get attachment filename without download attachment file in C++ or C# or Java? Which library support this?
|
|
|
|