|
Hi.
Do you still have the source code?
Thanks
|
|
|
|
|
Do we have any good effective WIN32 API which can tell whether my application is running on a system with a color v/s monochrome monitor attached.
A sample code snippet will be helpful.
Am using the following sample and apparently its not giving correct results always.
bool bColorMonitor = false;
// Get the display information
DEVMODE devmode;
if (::EnumDisplaySettings(NULL, ENUM_CURRENT_SETTINGS, &devmode))
{
//If dmDisplayFlags is set to zero then monitor is colored otherwise GrayScaled.
bColorMonitor = !(0x01 & devmode.dmDisplayFlags);
}
else
{
dirTrace.Error(_T("EnumDisplaySettings() failed"));
}
|
|
|
|
|
|
This is not giving what I want. It doesnt tell you whether the monitor attached to your system is a color or a monochrome monitor.
If some one tell me as to why EnumDisplaySettings doesnt work consistently with all types of monitors then that should be fine too.
|
|
|
|
|
If you want to consider a 'gray scale' monitor to be 'color' then you can just check the bits per pixel for the devmode.
If the BBP is 1, then it is monochrome. If it is more than that, then it is 'color' even if the color is shades of gray. You obviously need to do something else to distinguish color from gray scale, but at least this tells you 'basic' monochrome from 'everything else'.
I've seen better runs in my shorts! - Patches O'Houlihan
|
|
|
|
|
Ok, I've got a question about making modular applications. At least that what I call them. Basically, I have a bunch of classes, or rather just headers. Now for the implementations, I want to be able to create multiple implementaions of any class, and not have to recompile the whole program. So basically, say I have a class cWindowMaker. It has a Create_Window(x, y, width, height) function, and maybe some callbacks, but lets say it just has the Create_Window function. Now, I make an implementation that basically creates a window with all the bells and whistles, like the title bar, all the titlebar buttons, resizable, etc. And then I somehoe compile that implementation in a DLL file. Then, I load that DLL dynaically, create an instance of the class and call my Crete_Window function. Now, imagine I make another implementation, that basically makes a window without anything, no border etc. Make another DLL and now I want to use it. Well, obviously I jus have to replace the old DLL and restart my app and voila. The hard part? HOW do I make all that work?? Can't wrap my head around it. Can anybody please help? Im sure this kind of stuff has been done by somebody here before...
Thanks in advance.
rara avis in terris
|
|
|
|
|
A better approach would be to go through polymorphism: create a base class CWindowMaker that does nothing and create a class that inherits from it and implement its functionalities for a specific type of window (let's call it CWindowType1). You can create as many subclasses as you like and each of them implement a specific behavior.
Now, you can choose one or the other by using a pointer to the base class and create it the type you want:
CWindowMaker* pMyWindow = new CWindowType1;
Your pointer is still considered as a pointer to the bass class but in fact implements all the functionalitites defined in your CWindowType1 class. Using this mechanism, you can of course select your window at run-time (for example, ask the user to select the type of window and depending of his choice, create the correct instance, via a switch for example).
I suggest you read maybe some documentation about polymorphism, it could be helpfull.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
well, at least i got *A* reply...I do understand what you mean, get polymorphism quite well(ok, cant say i'm godly with my C++, but im fairly good). I do understand what youre saying. My original question is, however, how would I organize the same thing, but with CWindowType1 being implemented in a separate DLL...
say, CWindowType1 is implemented in WindowClass.dll
also, CWindowType2 is implemented in WindowClass2.dll
now, in my app I *somehow* tell it to load a DLL called "WindCls.dll", and call a function returns me a pointer to the class. The rest is as you say, yes. So, if I rename WindowClass.dll to WndCls.dll, then I get a pointer to a CWindowClass1. If however I rename WindowClass2.dll to WndCls.dll, I'd get a pointer to CWindowClass2. SO thats all fine and dandy, but the problem is how to actually make it so that I get that pointer from a DLL.
Hope that made a tiny bit more sense.
Thanks for the reply.
rara avis in terris
|
|
|
|
|
This can be done quite easily (I think  ). Make the base class a pure abstract class (so, an interface: no data and all method are pure virtual functions). So, you just have a header file for your base class.
Create dll1 and dll2 in which you implement CWindowType1 and CWindowType2 respectively. Both of these classes inherits from your interface (so, you have to include this base class in the dll's and in your project, that's why it's better to make it a pure abstract class).
In both dll's, add a public method called GetWindowClass (for example) that returns a pointer to the Base class (but in fact create a pointer to the derived class):
CBaseClass* GetWindowClass()
{
CBaseClass* pNewWindowClass = new CWindowType1;
return pNewWindowClass;
}
This way, you can handle every dll's exactly the same way and yet still implement different functionalities in it. Of course, you need to load your dll explicitely (with LoadLibrary and GetProcAddress) otherwise this cannot work  . Are you familiar with that technique ? If not, I suggest you take a look in the MSDN for more information.
So, what you will do at your program startup, is load the specific dll ("WindCls.dll" for example) and get the address of the function GetWindowClass (with GetProcAddress). Call it to get the specific pointer to the "windows system" and you can use it.
You need also to free this pointer later on but this can be done only in the dll. So what you have to do is implement a FreeWindowClass function in the dll that will simply delete the pointer.
And, as a bonus  : what you could also do, is write a factory class that will take care of loading several dll's so that you can change the windowing type whenever you want without needing to change the dll's names. But that's just for fun 
Hope this helps
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
I love you.....in a non-homosexual way.
Thanks. I kinda got the idea of DLL loading with LoadModule and GetProcAddress while waiting for a reply, but was just wanting something that others would recommend.
Thanks again.
rara avis in terris
|
|
|
|
|
2ASoft wrote: I love you.....in a non-homosexual way.
That was really funny.
Glad it helped.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Hi,
I have a class that wraps a COM object and has only 1 member, a pointer to the COM object (interface pointer) and several methods. It could also be any other pointer.
The size of an instance of this class is 4 bytes, there are no virtual methods or other members.
class CIntPtr<br />
{<br />
public:<br />
void AddOne () { (*m_pMyInt)++; }<br />
int *m_pMyInt;<br />
};
Is it now safe to cast an int* to an CIntPtr*?
int myInt = 0;<br />
int *myIntPtr = &myInt;<br />
<br />
CIntPtr *myIntWrapper = (CIntPtr *) &myIntPtr;<br />
myIntWrapper->AddOne ();
The code runs fine and I don't see any problem with this. Actually I would even say it is better than creating a new object and calling the constructor which makes a copy of the pointer. There is also no additional object that needs to be deleted.
But maybe this causes problems I'm not aware of.
|
|
|
|
|
I'm new to C++ (just a question), how can you use *m_pMyInt before you intialize it?
class CIntPtr<br />
{<br />
public:<br />
void AddOne () { (*m_pMyInt)++; } <-------use<br />
int *m_pMyInt; <-------intialize<br />
};
Just wondering.... or am I just stupid?
"C++ will solve any problem."
|
|
|
|
|
#hackC++ wrote: how can you use *m_pMyInt before you intialize it?
Have a look at the other code, I'm 'faking' an object.
Or do you mean declare instead of initialize? It's common practice to have the members at the bottom of the class and the methods at the top.
|
|
|
|
|
You're being too clever for your own good. Casting pointers like that may work, on your current OS and current compiler. There's no guarantee it will work on others or even future versions of your current compiler.
ABuenger wrote: Actually I would even say it is better than creating a new object and calling the constructor which makes a copy of the pointer.
A temporary object of CIntPtr can be created and deleted very quickly. Again, you're being too clever, and besides unless you're creating billions of temp objects, you're not going to see any speed increase on any computer built this century.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
I agree that this kind of technique should be avoided; but as long as you’re careful it should work on all standard compliant compilers. As long as you don't have any virtual functions the layout will be compatible with that of the member. The layout of a struct or class is predictable and standard for the most part. Certainly for a simple class with no base classes or virtual functions it is.
Steve
|
|
|
|
|
It's not a question of whether it works, it's a question of whether code like that should be written in the first place. If I saw code like that, and I knew nothing else of the author, I'd be highly suspicious of his grasp of C++ basics.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
As I said, "I agree that this kind of technique should be avoided". My comment was motivated by your statement that, "Casting pointers like that may work, on your current OS and current compiler. There's no guarantee it will work on others or even future versions of your current compiler." This need not be the case: the layout of structures in C/C++ is well defined. This is why a struct can be used to write to the registers on a hardware device in device drivers for example. In short, code like the OP's can be made to work portably although in general it should be avoided.
Steve
|
|
|
|
|
This is just another way of exploiting power of pointers provided by C++. But this is not considered as good practice.
|
|
|
|
|
ABuenger wrote: Actually I would even say it is better than creating a new object and calling the constructor which makes a copy of the pointer.
This is an illusion. Firstly note that sizeof(CIntPtr*) == sizeof(CIntPtr). This means that, from a storage point of view, there is no difference. i.e.
class CIntPtr
{
public:
CIntPtr(int *pInt = NULL) : m_pMyInt(pInt) {}
void AddOne () { (*m_pMyInt)++; }
int *m_pMyInt;
};
int myInt = 0;
int *myIntPtr = &myInt;
CIntPtr *myIntWrapper = (CIntPtr*)&myIntPtr;
CIntPtr myOtherWrapper(&myInt);
In short the advantages of this confusing technique may be imagined.
Steve
|
|
|
|
|
Hi all,
Has anyone encountered some VERY STRANGE problems with layered windows, when using the CWnd::UpdateLayeredWindow() API call?
I have had success and failures using the SAME call from within the constructor of my CWnd derived class. My "success" is determined by the classname used when the window was created.
I'm calling UpDateLayeredWindow() this way:
BOOL bResult = UpdateLayeredWindow( NULL, &ptDest, &size, &mem,<br />
&ptSrc, byAlpha, &m_Blend, ULW_ALPHA);
Note "mem" is a screenCompatible CDC, on which a bitmap was drawn via code(simple rectangular fill), and size is the size of the CBitmap object selcted into the mem CDC.
1) Partial success if created using -
CWnd::CreateEx(WS_EX_LAYERED |WS_EX_TOPMOST|WS_EX_TOOLWINDOW, "STATIC",<br />
_T(""),WS_VISIBLE|WS_POPUP, 300,300,200,200,NULL, NULL, NULL );<br />
my window appears, but doesn't receive mouse events.
2) Failure, if I create it using:
CreateEx(WS_EX_LAYERED |WS_EX_TOPMOST|WS_EX_TOOLWINDOW, m_lpszClassName,<br />
_T(""),WS_VISIBLE|WS_POPUP, 300,300,200,200,NULL, NULL, NULL );
where
m_lpszClassName = AfxRegisterWndClass( CS_VREDRAW | CS_HREDRAW | CS_OWNDC );
The bitmap does NOT appear. I have to do a bitblt of the mem to screen to see it appear, preceded by a MoveWindow call. But then I receive mouse events.
I find this baffling. Does anyone else have any insight into this situation?
Thanks for anything info you can provide!
Jeanne Sim
-- modified at 19:22 Thursday 15th June, 2006
|
|
|
|
|
Hello,
When you define in some function a critical section you define a critical section block or variable ?
I will explain - when some thread get to this Critical section and the Critical section is lock - so this thread will go sleep until this Critical section will be unlock and the event will be called to rise up.
But my problem (or my bad understanding) is about the block of the critical section - i think that the critical section is only to block thread and make the thread sleep and have no direct connection to the block - but some other thought is that the critical section is define only on block.
Can someone explain the main idea of the critical section in this case ?
Thanks on any help. 
|
|
|
|
|
There are numerous good articles about this:
Check Here.[^]
----------
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
- Laurence J. Peters
|
|
|
|
|
yanshof wrote:
Can someone explain the main idea of the critical section in this case ?
See here.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I read those both and i still have the same question.
My question will not appear in there.... like i said this is hard question...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
