|
When you change the viewport and window extents, you will suffer from "off by one" errors. This is inherent in how non MM_TEXT mapping modes work and the algebra used for the metric translations. Those errors become evident when you apply offscreen buffering techniques such as described by Petzold, Jones, and in Keith Rule's article here on codeproject. His example claims to support MM_ANISOTROPIC but if you examine his source code, you will find he leaves the viewport and window extents at 1 which is effectively the same as MM_TEXT and when applied to the algebraic equations will not cause off by one errors. Obviously, MM_ANISOTROPIC and MM_ISOTROPIC would be useless if used without setting the extents as this is what provides the scaling. (By the way, that's not a bash on the authors as their code helps greatly, just a matter of factly statement)
If you are using a variant of one of the published authors memDC and using MM_ISOTROPIC, this is likely what you are suffering from or will find you are suffering from later.
One way to verify this is to turn on "Show windows contents while dragging" in the display properties/appearance tab/effects button. Drag the help/about box from your application over your client area in random paths and if it "smears" or "smudges" your drawings then you are suffering from this.
It basically involves the calculation of the clipping rectangle and the fact that there is a LPtoDP and a DPtoLP involved explicitly and indirectly by the windows API functions. If your familiar with the "pigeon hole principle" then you already understand the fact that a round trip could cause a loss of data. Hence the off by one error that leaves a single pixel width not refreshed on the edge of the clipping rectangle.
Some people never notice it because they have the "Show windows contents while dragging" turned off so as they resize the window or drag something over it, they only see a tracker rect and not the leftover non refreshed edges. I posted a reply in Keith's article linking to a helpful MSDN article that helped me realize how get past this (somebody didn't like my response there, got a 2 vote probably because I didn't post the code or something). In a nutshell, you need to calculate the rectangle that is used for the bitmap and the blit without any LPtoDP or DPtoLP round trips. here[^]
|
|
|
|
|
Thanks for your help. I think it was useful and I'll try it. And, I also made one mistake: I used OWN_DC style for my window(I feel shame for it). I guess that's why I usually got incorrect clipping rectangles, since they were already rounded by windows.
|
|
|
|
|
Hi All .
How is it possible to distinguish that the thread is in suspend mode or resume(running) ?
Thanks a'lot.
|
|
|
|
|
You'll need to keep track of that yourself.
It may help to take a look at the .NET Thread class ThreadState property and ThreadState
enumeration for hints on a way to track thread state.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
First let me apologize that I did not keep good records about this.
My machine got invaded and I lost few things during the rebuild.
There is a registry key that integrates VC6.0 with VSS.
Could anybody send me this information, please.
It would save me reinstall time and further aggravation.
Thanks a lot Vaclav
|
|
|
|
|
Okay... I have embedded a manifest in my project:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Meh! Test"
type="win32"
/>
<description>Program Description</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
I have added as a resource:
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "Meh! Test.exe.manifest"
I have called InitCommonControlsEx for every ICC_x there could be:
INITCOMMONCONTROLSEX iex;
iex.dwSize = sizeof(INITCOMMONCONTROLSEX);
iex.dwICC = ICC_LISTVIEW_CLASSES|ICC_TREEVIEW_CLASSES|ICC_BAR_CLASSES|ICC_TAB_CLASSES|ICC_UPDOWN_CLASS|
ICC_PROGRESS_CLASS|ICC_HOTKEY_CLASS|ICC_ANIMATE_CLASS|ICC_WIN95_CLASSES|ICC_DATE_CLASSES|
ICC_USEREX_CLASSES|ICC_COOL_CLASSES|ICC_INTERNET_CLASSES|ICC_PAGESCROLLER_CLASS|
ICC_NATIVEFNTCTL_CLASS;
InitCommonControlsEx(&iex);
InitCommonControls();
But I still have the win95 edit control.
(All other common controls are styled correctly though)
Any help would be well apreciated...
PS: I am using Visual Studio C++ Express 2005 with Updates
PSS: Yes, I have included commctrl.h and 'commented in' comctl32.lib
|
|
|
|
|
You could maybe include the manifest as a separate file in the directory which your application is in - call it [your application name including .exe].manifest (for example, if your application was called test.exe, the manifest would be called test.exe.manifest). Also, when you say "all other common controls are styled correctly", have you tried all of the controls, because some controls (for example scroll bars) have the XP styles applied whether or not you use a manifest, so maybe the manifest resource hasn't loaded properly.
Hope this helps!
--PerspX
|
|
|
|
|
Hi all,
I've hunted around, but can't seem to find anything on this. I could be searching for the wrong keywords.
What I'd need to do, is monitor all the shares on the local pc, and take note of open files, and which user has the files open. So far I can use NetSession enum to get some info, but it gives me "[::1]" in the sesi2_cname field. It doesn't tell me what files are open though for the user it tells me about.
Does anyone have any recommendations?
Cheers
Jubjub
"If you're too careful, your whole life can become a f---in' grind." - Mike McD ( Rounders)
|
|
|
|
|
Finally found what I needed.
Use NetFileEnum.
"If you're too careful, your whole life can become a f---in' grind." - Mike McD ( Rounders)
|
|
|
|
|
thanx mate,
Im looking for the same kinda functionality too.
Want to make an app similar to yours to manage my network shares.
|
|
|
|
|
Hi All,
I am an intermediate C++ programmer and have a question on the casting operators in C++ when converting between integral data types. My question is as follows:-
If I have a code like this
char c;
int i = 65;
c = i;
VC++ 2005 Complier gives a warning as "possible loss of data. conversion from int to char. So to remove the warning I have the following choices
1. Disable the warning by using #pragma warning (XXXXX:disable). I do not want to use this.
2. Use C style cast to remove the warning as
c = (char)i;
Again I do not want to use this option
3. Use C++ casting operators. I can use either reinterpret_cast as
c = reinterpret_cast<char&>(i);
or static_cast as
c = static_cast<char>(i);
However I am confused between the correct usage. Both these casting operators removes the warning and also gives the desired result.
Can someone please clarify which is the correct usage and if that usage has any side effects?
Thanks and Regards
|
|
|
|
|
The C style cast is fine in this case. If you want to use C++ style casts then use static_cast, because they are similar types. The ‘ reinterpret_cast if for converting between unrelated types, such as an ‘unsigned long’ to a pointer.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
psychedelic_fur wrote: 2. Use C style cast to remove the warning as
c = (char)i;
Again I do not want to use this option
Just out of curiosity, why is this option undesired in your situation? From the little I've seen in Java and C#, it appears this is the common form. You understand what it will do in most contexts (especially this one) and it's easier to type and read. You can search for, and find them just as easy in code.
I've never bought the arguments for why the C++ style is superior as no text or article has ever offered a solid affirmative that was not easily rebutted. The examples offered always seem a bit contrived and not so commonplace. I've used this style since the early 90's and it works just fine.
I'm sure someone will pounce on my post with some obscure way to misuse or abuse it but that would be expected as most of the C++ purists are a bit fanatic.
|
|
|
|
|
I do not know about C++ purist, but us old C programmers where definitely known for that. In both C and C++ the C style cast works fine most of the time, and in this case there is no reason not to use it.
I am still not sure why static_cast and reinterpret_cast even exist. On the other hand dynamic_cast is a must for safety, even if we did not have something similar in C.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
John R. Shaw wrote: On the other hand dynamic_cast is a must for safety, even if we did not have something similar in C.
I don't think I've ever compiled with the RTTI enabled but I'm the kind of person who uses objects more to group my code logically than for complicated inheritance. I've always stayed at the shallow end of the OOP pool. 
|
|
|
|
|
John R. Shaw wrote: dynamic_cast is a must for safety
So is static_cast. You use it when you want the efficiency of a C-style cast but with more type safety. static_cast can not cast between unrelated types. See here[^] for an example.
Steve
|
|
|
|
|
I have never considered using static_cast on derived classes (types), only on integral data types. I also would not use a C-style cast on derived type (it’s just wrong), because I prefer to have the extra safety of C++ casting when it is necessary for such casting. When converting from int to char, or vise versa, I use C-style casts normally. I rarely need to do any casting and when I do I make sure it is done correctly.
P.S. I have read all the posts to date.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I know that the old C style cast works well in this case however I just wanted to find out what is the correct C++ equivalent. It is just out of curiosity. Conside another example
BOOL isCorrect = TRUE;
bool bvalue = (bool)(isCorrect); --- Gives warning C4800
In this case the complier still gives me warnig at Level 4 and the static_cast also doesn't remove the warning (though both of them works and gives the correct result)
bool bvalue = static_cast<bool>(isCorrect); --- Gives warning C4800
the only thing I can do here to remove the warning and get the correct result is use reinterpret_cast as
bool bvalue = reinterpret_cast<bool>(isCorrect) --- error, doesn't compile
bool bvalue = reinterpret_cast<bool&>(isCorrect); or equivalent pointer variation
bool bvalue = *reinterpret_cast<bool*>(&isCorrect);
This works since both "bool" and "BOOL" are basically different types.
I was a bit surprised to find that even old C style cast did not remove the warning, since C style cast is supposed to convert anything into anything.
Thanks
|
|
|
|
|
Fair enough.
I'm not going to claim to know why but I'll take a guess at it.
In VC++ 4.2 on up (likely compiler specific),
BOOL will always maintain it's integral value while bool only allows 2 values for it's type. For instance...
BOOL BOOLVal=5;
TRACE("BOOLVal(5) = %d\n",BOOLVal); // 0 = FALSE. All other values = TRUE
// outputs 5
bool boolVal=(bool)-42;
TRACE("boolVal(-42) = %d\n",boolVal); // Always 0 or 1 (false or true)
// outputs 1
A cast (as we've come to expect it) from BOOL to bool in this case should still truncate the integral value and maintain the bits for the first 8 bits but since bool only allows true and false as 1 and 0, an additional conversion, besides the cast must take place. I'm guessing that's where this operation is no longer a cast and becomes a translation of the value.
// Assembly for a BOOL=bool
119: BOOL isCorrect = 56;
00401973 mov dword ptr [ebp-1Ch],38h
120: bool bvalue = isCorrect;
0040197A xor edx,edx
0040197C cmp dword ptr [ebp-1Ch],0
00401980 setne dl
00401983 mov byte ptr [ebp-20h],dl
// Assembly for a BOOL=BOOL
119: BOOL isCorrect = 56;
00401973 mov dword ptr [ebp-1Ch],38h
120: BOOL bvalue = isCorrect;
0040197A mov edx,dword ptr [ebp-1Ch]
0040197D mov dword ptr [ebp-20h],edx
/*
The setne instruction is "Set byte if not equal (ZF=0)" and it's description says "Sets the destination operand to 0 or 1 depending on the settings of the status flags
(CF, SF, OF, ZF, and PF) in the EFLAGS register"
*/
This is where I'm guessing the translation occurs versus a true cast and probably explains why the compiler takes the liberty to provide warnings. Also, it appears that there is a little history to bool in VC++ changing around version 4.2 and I would guess the warning is to give programmers with code written prior to the version 4.2 change an extra heads up to a potential "breaking change".
Not sure if I got that right but it seems reasonable.
|
|
|
|
|
reinterpret_cast is a compile-time cast between a pointer type and a non-pointer type, or between unrelated pointer types. static_cast is used for all other compile-type typecasts (but it's your responsibility to make sure the cast makes sense).
I always use the C-style casts because they're easier to type, cause less noise in the code, and work just as well as the C++ ones.
|
|
|
|
|
I never use C-style casts except in low level code (such as code that grovels around in a PE file, for example). The code “noise” you refer is a feature and something which, in my opinion, should be embraced rather than shunned. Casts should be both explicit (you cast for many different reasons but they all look the same with C-style casts) and visible (it’s easy to “grep” for C++ style casts and they stick out). The C++ style casts are also safer, for example:
#include "stdafx.h"
#include <iostream>
using namespace std;
class NoClassesDeriveFromMe
{
public:
void Who()
{
cout << "NoClassesDeriveFromMe" << endl;
}
};
class BaseClass
{
public:
void Who()
{
cout << "BaseClass" << endl;
}
};
class DerivedClass : public BaseClass
{
public:
void Who()
{
cout << "DerivedClass" << endl;
}
};
int main(int arvc, char* argv[])
{
NoClassesDeriveFromMe d;
((DerivedClass&)d).Who();
static_cast<DerivedClass&>(d).Who();
return 0;
}
Steve
|
|
|
|
|
#include "stdafx.h"
#include <iostream>
using namespace std;
class BaseClass
{
public:
int m_nValue;
BaseClass() : m_nValue(2)
{
}
void Who()
{
cout << "BaseClass " << m_nValue << endl;
}
};
class DerivedClass : public BaseClass
{
public:
int m_nValue;
DerivedClass() : m_nValue(3)
{
}
void Who()
{
cout << "DerivedClass " << m_nValue << endl;
}
};
int main(int arvc, char* argv[])
{
BaseClass b;
static_cast<DerivedClass&>(b).Who();
// An error but will compile.
// Not as safe as you'd like it to be.
return 0;
}
|
|
|
|
|
It's as safe is it can reasonably be without runtime overhead. There is a relationship between the two classes (some BaseClasses are DerivedClasses) so the cast will succeed; if there is no relationship (no BaseClasses are DerivedClasses) then it fails. In the general case there is no way a compiler can be expected to detect if a particular base class instance is related to a particular derived class (they simple aren't smart enough and separate compilation complicates this even further). If you want complete safety you’ll have to pay a price at runtime and use dynamic_cast.
No one's suggesting that using static_cast will solve all your problems, just that it’s safer than a C-style cast.
Your point is taken however.
Steve
|
|
|
|
|
Here’s a more subtle variation on the same theme as the previous post. Pay particular attention to the "Actions.cpp" file and the comments inside it. I have seen this in real life. Although it seems contrived in a small demo program like this, in the real word it’s not esoteric at all. Real programmers do indeed try to speed up compile times by removing a header and seeing if the program still compiles: in this program, if C-style casts are used, removing a header results in a program that still compiles but behaves incorrectly at runtime. C-style casts, "just say no".
=============================================================
CastProblems.cpp
=============================================================
// CastProblems.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "Classes.h"
#include "Actions.h"
int main(int argc, char* argv[])
{
Derived d;
GetBase2(&d)->Who();
return 0;
}
=============================================================
Actions.cpp
=============================================================
// Actions.cpp
//
#include "StdAfx.h"
#include "Actions.h"
#include "Classes.h"
// If C-style cast is used below:
// - If this header is included the output is "Base2" (correct).
// - If this header is not included the program compiles but the output is "Base1" (incorrect)!!!
// If a 'static_cast' is used below:
// - If this header is included the output is "Base2" (correct).
// - If this header is not included the program doesn't compile.
const Base2* GetBase2(const Derived *pDerived)
{
// return (const Base2*)pDerived;
return static_cast<const Base2*>(pDerived);
}
=============================================================
Actions.h
=============================================================
// Actions.h
//
#ifndef __ACTIONS_H__
#define __ACTIONS_H__
class Base1;
class Base2;
class Derived;
const Base2* GetBase2(const Derived *pDerived);
#endif // !__ACTIONS_H__
=============================================================
Classes.h
=============================================================
// Classes.h
//
#ifndef __CLASSES_H__
#define __CLASSES_H__
#include <iostream>
class RootBase
{
public:
void Who() const
{
using namespace std;
cout << "Base" << m_Num << endl;
}
protected:
RootBase(int num) : m_Num(num) {}
int m_Num;
};
class Base1 : public RootBase
{
public:
Base1() : RootBase(1) {}
};
class Base2 : public RootBase
{
public:
Base2() : RootBase(2) {}
};
class Derived : public Base1, public Base2
{
public:
};
#endif // !__CLASSES_H__
Steve
|
|
|
|
|
Use static_cast; reinterpret_cast is the wrong choice in this context.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
