Not sure (been a while since I used GDI), but maybe you should create a compatible bitmap and select it into the device context before drawing to it?

Dalek Dave wrote:

And how long has it been since you saw "Insert next disk into Drive A:"

I have not come across it ever (not that old), but I came across http://forums.impulsedriven.com/406173[^], where on some systems Dragon Age 2 was requesting the user insert the disk into the A Drive.

permutations wrote:

literally identical (I put the DOS code in a DLL).

This could be part of the problem; if the code is compiled for 16 bit and DOS, the emulation needed for it to work at all would slow it down. Plus depending on the implementation of said emulation, it may be artificially making it run slower to better mimic the original platform. You may want to consider porting the program to target Windows (32 bit at least).

It would seem that like most modern operating systems, the one you are using makes use of paging; therefore all addresses are fake. Therefore it can load them to diffrent real addresses, and tell the program it is at the address it was meant to run at (all programs are compiled to run at a specific base address).

Try searching for articles on Code Project, with the search term "plain", C as the langauge, and COM as the technology. There is atleast one series of articles here on the subject, and you will be better off as using COM in C is complicated (but given that there are articles about it, doing so is possible).

One thing that helps me is having a desktop theme with dark background colors, and light colored text. It is like having the screen on a lower brightness setting, except it does not make things harder to see. Unfortunatly, many websites / programs assume the opposite, so it can lead to problems :sigh: .

For some reason I was stuck on thinking in terms of normal math. Still, you should really make sure such a problem has an answer before presenting it as a puzzle.

It cannot be done within the given specifications, as the function is discontinuous.

GetExceptionInformation[^] combined with typeid (if it has virtual functions) are your best shot for a simple solution; otherwise you may want to look up some articles on exception handling for C++.

To define an operator out side of a class, you place "friend" before the return type.

class A {
public:
A(int x) :num(x) {}
~A() {}
int GetVal() {return num;}
friend std::ostream& operator<<(std::ostream& o,A& a) {return o << a.GetVal();}
private:
int num;
};

Which is the same as:

class A {
public:
A(int x) :num(x) {}
~A() {}
int GetVal() {return num;}
private:
int num;
};
std::ostream& operator<<(std::ostream& o,A& a) {return o << a.GetVal();}

modified on Tuesday, April 20, 2010 5:55 PM

Yes and no, I am doing this because I had once tried to create a fullscreen window and I found an upper limit on the size of a window. This was to see if I had found how to work around that, which I seem to have done. The question is about the possible cause of an oddity I noticed in the process. Thanks for the links, I think they will be useful soon.

It is an inline function; x, y, width, and height are values passed to it. In the case this thread refers to: x = 0, y = 0, width = GetSystemMetrics(SM_CXSCREEN), height = GetSystemMetrics(SM_CYSCREEN). AdjustWindowRect causes the bottom and right member variables to be adjusted such that if you create a window using them, the height and width of the client area will be equal to the original values of those variables. This is simpler and less error prone than figuring it out myself. Do to the nature of the redraw code as it stood at the time I was doing this, everywhere that was not drawn to would be filled with black. I know this because I am doing the drawing with OpenGL and when I had a matrix out of place (it was the default matrix, so only the upper right was being drawn). So that is not an issue.

RECT r;
x -= ::GetSystemMetrics(SM_CXFIXEDFRAME);
y -= ::GetSystemMetrics(SM_CYCAPTION)+::GetSystemMetrics(SM_CYFIXEDFRAME);
r.right = width;
r.bottom = height;
AdjustWindowRect(&r,0,0);
obj.handle = CreateWindowExA(WS_EX_TRANSPARENT|WS_EX_TOPMOST,"CONTEXT",title,0,x,y,width,height,0,0,::GetModuleHandle(0),0);

The WndProc associated with it is crafted to make it as though the non-client area does not exist; it is not drawn, it does not recieve input, hit tests return true only if the point is inside the client area, and WM_NCCALCSIZE returns WVR_VALIDRECTS|WVR_REDRAW (for now, I will do some custom checking later). For getting the size and position, I use GetClientArea, as the client is effectivly the entire window. The window is filled with a rectangle of its width and height when redrawing. Looking it over it might be that I should use SM_CXBORDER insead of SM_CXFIXEDFRAME, but that would not account for all the missing space.

std::cout << ::GetSystemMetrics(SM_CXSCREEN) << '\t' << ::GetSystemMetrics(SM_CYSCREEN) << std::endl; The output is the expected value (my screen resolution), and the related output for the window size and position is what I expected as well (the as I passed to CreateWindowEx). However, since I can see that the window is smaller than the screen, it means one of the values is a lie.

Same parameters, and it is returning th expected values (the same as my screen resolution).

This might be (at least partly) resposible.

Well, if you are able to access the HWND, you can use GetWindowLongPtr[^], SetWindowLongPtr[^], and CallWindowProc[^]. GetWindowLongPtr will get you the address of the funcion, then you can set it to the custom procedure, which can then call the old procedure.

While messing around with Windows programming I found something odd. When I have a window at (0,0), and the width is 1680, the height is 1050, and GetSystem metrics says that is the height and width of the screen; however the window does not fill up the entire screen. (e.g. there are exactly three pixels it does not cover on the right) Any thoughts was to what might be happening? --------------------- Okay, two things to add: - Since I had altered the message processing so that it would be as if the non-client area did not exist, I was using GetClientRect to find the values for position and size. It sets left and top to zero, so the position could have been wrong. :doh: - I had shifted the window up and to the left to place the 0,0 of the client area at 0,0 on the screen. Further testing shows that the calculations I had preformed were correct for a window with no style so this should not have been a problem. Therefore it would seem I have somehow managed to prevent the non-client area from being created, as all non-child windows normally have a border of some type and a caption even if those things are not specified in the style. Will confirm this later with a few more tests. --------------------- Apperently there is no non-client area if you eat the WM_NCCALCSIZE message, so my adjustments to the windows position to account for the non-client area was unneeded. This fact is not in the documentation of the message :(( . Would have saved a lot of trouble. So, my code was correct per the documentation of the Windows API, but it was something they forgot to mention that was the root of the problem (as I had expected, though I was looking in the wrong place).

Yes if the destructor is not virtual, no if it is. Delete will take any type, but it will only call the appropriate destructor if it is virtual or if you pass it as the correct type.

If I understand what you are asking, then it should be something like this: - a.h

class ClassOne {
//stuff
void SetRef();
//more stuff
};
static ClassOne* one;

- a.cpp

one(0);
inline void ClassOne::SetRef() {one = this;}

Your problems are: - "this" is only valid inside class member methods. - You do not need to have "ClassOne::" infront of "one" unless it is a static member of the class (it is declared within the scope of the class). If "one" is a static member, this a.cpp would be as follows:

ClassOne * ClassOne::one(0);
inline void ClassOne::SetRef() {ClassOne::one = this;}