|
Just to give you some follow-up advice, by declaring your static outside of your class, you've just made him a global variable. Now anyone can access him and he's polluting your global namespace.
If you want to keep him both private and keep him contained within SaveClass. Declare it inside of SaveClass and instantiate him in the cpp file.
class SaveClass
{
public:
SaveClass(void);
~SaveClass(void);
int Get() const;
int Set(int var);
private:
static int m_testVariable;
};
int SaveClass::m_testVariable = 1;
|
|
|
|
|
Hi,
would anyone know the message that is genertasted by the FrameWork for CASynsocket::OnConnect
as my connect fails with 10035 WSAEWOULDBLOCK however my OnConnect overridlable is never called
|
|
|
|
|
Internally, this is based on a callback scheme and using WM_SOCKET_NOTIFY . You shouldn't try to intercept that message though because it gets sent to an internal window in CAsyncSocket (so, yes... if you intercept the message, you'll essentially break what the framework is trying to do).
|
|
|
|
|
I have a child window showing a custom message with notification icons in it. I am showing that on the title bar of parent window and I am calling OnPaint of the child window in the OnPaint of the parent window frame class.
Issue:
How can I find the color of the parent window title bar so that I can use the same color in the child window? I want the child window to blend in with the parent window title bar.
|
|
|
|
|
If you use the MFC framework, the title bars should already be the same color (that's managed by the framework, since the OS allows you to change the theme colors). So, not sure what king of setup you have going on, maybe show some code, of importance would be how you're deriving your classes and your custom OnPaint.
|
|
|
|
|
There is a GetPixel[^] API that you can use which will give you the color value for a point on a window that belongs to a device context.
|
|
|
|
|
Hello,
from a MFC program I need to send data to an external USB Device.
System: Windows XP SP3, MS Visual Studio 2008, WinDDK (most current).
Because I don't have any valid documentation I used a sniffer showing me the used commands.
GET_DESCRIPTOR_FROM_DEVICE and BULD_OR_INTERRUPT_TRANSFER
Using CreateFile I can successfull connect to the device.
But I failed to use DeviceIoControl.
HANDLE result = CreateFile(dev_name, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
USBSCAN_GET_DESCRIPTOR data1;
DWORD bytesReturned;
BOOL b = DeviceIoControl(handle, IOCTL_GET_USB_DESCRIPTOR, NULL, 0, &data1, sizeof(USBSCAN_GET_DESCRIPTOR), &bytesReturned, NULL);
Error C2065 "USBSCAN_GET_DESCRIPTOR"
After including "usbscan.h" I get C2065 on METHOD_BUFFERED and FILE_ANY_ACCESS and C3861 on CTL_CODE.
When including wdm.h I get about 107 errors in driverspecs.h and kernelspecs.h.
So please, can anybody help me to get this run.
Thanks
Stefan
|
|
|
|
|
What is the USB device? It could be a USB com port, a USB network card for example. If so use the usual API to access it. COM API or sockets.
Dont forget USB is just the protocol between the system and the hardware, at the app level it really is irrelevant.
==============================
Nothing to say.
|
|
|
|
|
Hello,
its a medical device having leds. I have the commandsets to enable or disable them.
But I cannot send any commands.
Stefan
|
|
|
|
|
How does the system see the device? ie, in DeviceManager.
==============================
Nothing to say.
|
|
|
|
|
Hello,
it shows under "custom usb devices" as "[Company Name] Familiy Device".
Stefan
|
|
|
|
|
Hmm, so its not presenting itself as a well known device then. What sort of driver is sitting on the device? (ie what are the names)
Is there an inf file with a custom driver for example? If so you will need documentation on the interface to that driver. The mnuf should be able to provide it.
==============================
Nothing to say.
|
|
|
|
|
solved
http://www.codeguru.com/forum/showthread.php?p=2053720
|
|
|
|
|
I'm thinking it would be a wee more efficient if winioctl.h and usbscan.h were added to the project's stdafx.h file.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Hi
I am trying to use "InvalidateRect" to paint part of screen. When I move a drawing a little faster, there will be some dirty left on screen.
How can I get rid of the screen dirty? Some code sample would be appreciated.
Best,
|
|
|
|
|
transoft wrote: there will be some dirty left on screen.
Please clarify, it is not clear where this occurs or what exactly you are referring to. You could also show some of the code you use to repaint your window.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Thank you for your reply.
I just used following code:
InvalidateRect( rect, true );
Then I picked one drawing using mouse and drag it ( move it) to other place. when I move the drawing very slow (using mouse to move it slowly), it looks OK. But a little bit faster, there will be some dirty (some drawing not cleared) left on screen. Is there a way to avoid this?
Best,
|
|
|
|
|
transoft wrote: Is there a way to avoid this?
Yes, but I cannot recall the method. I think it's something to do with capturing the mouse and delaying repaint of the Window. Try a search on MSDN for what you are doing and see if you get any good hits.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
What are you invalidating? ...this may be caused by you invalidating only a small portion of a window independent of the rest of the window (causing unnecessary redraws) or by invalidating somewhere where you probably shouldn't (also causing unnecessary redraws).
You really need to share more of the code for a more definitive solution.
|
|
|
|
|
Yes, I just want to invalidate the drawing area that I am moving.
What I am doing is:
(1) while "mouse moving", I send out "InvalidateRect".
(2) do the Invalidating job
I think the problem coming from the delay "InvalidateRect" and actual paint. I also tried "RedrawWindow" without any success.
Thank you for your reply!
|
|
|
|
|
InvalidateRect() does what it is supposed to do. If you are leaving mess on the screen, it is because your rectangle is wrong / too small / etc. Or if your Invalidate / Paint rectangle is mismatched. What I mean is, if you move the mouse fast, you might erase 0,0,100,100, but by the time you get to the paint, you are working on rectangle 10,10,110,110. Also, how are you getting the rect to paint? The one that comes in through GetUpdateRect() is often wrong / slightly off.
|
|
|
|
|
Thank you very much for your reply.
I calculated the drawing rectangle that I need to move. AND I also enlarge the rectangle by 1.3 factor. I am sure the problem is not from the region that needed to be updated.
The problem is that when I move the drawing slowly, everything is OK, but a little faster, there will be some mess on screen.
Thanks again!
|
|
|
|
|
transoft wrote: I am sure the problem is not from the region that needed to be updated.
Then you would be highly mistaken sir!
Win32 drawing is message based (WM_ERASEBKGND & WM_PAINT). When you move slowly, you are getting all the messages point by point and your painting works correctly. When you are moving quickly, you MAY NOT get all messages. Windows is not going to send you a message for every single point when you are moving the mouse around like a crazy person! It compensates for that by skipping points.
What I indicated in my original response is your issue. 100% guaranteed.
You draw something at 0,0,100,100 and then move the mouse so quickly, the system never sends you an erase / paint cycle for 0,0,100,100 because you are already at 10,10,110,110.
For example:
Enlarging the rectangle by 0.0 may work for moving the mouse up to "10MPH"
Enlarging the rectangle by 1.0 may work for moving the mouse up to "20MPH"
Enlarging the rectangle by 2.0 may work for moving the mouse up to "50MPH"
So you get excited and enlarge the rectangle by 3.0 and everything works perfectly, right? NO. Everything works perfectly on YOUR machine which is a super duper gaming machine with a high end video card.
Then you take your app over to Bobs machine which has a lousy graphics card, anti-virus app running in the background and is cluttered with spyware from all his porn sites.
On Bob's machine, your app only works for moving the mouse up to "7MPH" and you get furious and start foaming at the mouth all angry!
True story .
I have been doing Win32 GUI apps for 16 years and am a custom control master. I am fully aware of how the system works and all the nuances .
BOTTOM LINE: if your update rectangle was correct, you wouldn't be here posting your question, now would you?
Over the years, I have learned that painting by update region is often a practice in futility and you will never get it perfect across machines at every mouse speed / video card combo.
You **MUST** double buffer your screens and keep track of what you drew on. DO NOT RELY ON WINDOWS TO SEND YOU ALL POINTS!!!
One other option is to realize that today is the year 2012 and move on to a "big boy" architecture like WPF where we don't worry about such nonsense anymore . MFC was fine in 1986. Sorry , had to be said . I don't program in Win32 / MFC anymore after all these years because I refuse to deal with crap like pixel droppings anymore and instead focus on the application .
But my response still stands. Your update rectangle can NOT be correct or your app would be working. It is not necessarily your fault... Win32 just doesn't feel like sending you all the information you need to do your "optimized" drawing.
|
|
|
|
|
Several things come to mind:
1. The parameter "rect" refers to only the "area" that will be invalidated. If the objects you're moving occupy the entire client area, try using the function as follows: InvalidateRect(NULL);
2. With a little more work you may want to "buffer" output for speedier and flicker free operation.
3. Examine GDI+ as an alternative
|
|
|
|
|
I am getting a 0 Return Code from CAsynSocket::connect doing GetLasterror I am getting
WSAEWOULDBLOCK 10035 (waitting for connection to complete)
However my CAsynSocket::Onconnect overridable is never called to complete the connection
Any Suggestion would be helpfull
|
|
|
|