|
First store your Image in MemoryDC.
then call Invalidaterect();
You will get code in KRUGLANSKI.
|
|
|
|
|
If the window flickers it must mean that something else is being drawn to it between each of your StretchDIBits calls (otherwise you'd just be blitting the same image over the top of itself and you'd see no flicker).
Probably what's causing the flicker is that your window's background is being erased as part of the repaint. However, if your image fills the window this erasing is entirely unnecessary and you should prevent it.
An easy way to do this is to trap the WM_ERASEBKGND message and return zero -you should then find that that flickering goes away.
|
|
|
|
|
Hi,
I have tried to override OnEraseBkgnd, the problem still occurs. I am writing and ViewLCD application for a camera (just like a digital camera with an LCD at the back to view the scene that the camera is pointing to).
Thanks,
|
|
|
|
|
Well, the flicker will only appear if something other than your bitmap is being drawn between your updates - the obvious candidate is erasing the backrgound but is there anything else in your WM_PAINT processing that might be causing this?
|
|
|
|
|
This is all in my OnPaint() of a CChildView:
CPaintDC dc(this); // device context for painting
CDC* pDC = &dc; // Convert to context device pointer
HDC hdc = pDC->GetSafeHdc();
// Prepare Header for image
BITMAPINFO *m_pBitmapInfo;
m_pBitmapInfo = (BITMAPINFO*)new char[sizeof(BITMAPINFO) + sizeof(RGBQUAD)*256];
// Load header
m_pBitmapInfo->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
m_pBitmapInfo->bmiHeader.biWidth = ImX;
m_pBitmapInfo->bmiHeader.biHeight = -ImY;
m_pBitmapInfo->bmiHeader.biPlanes = 1;
m_pBitmapInfo->bmiHeader.biBitCount = 8;
m_pBitmapInfo->bmiHeader.biCompression = BI_RGB;
m_pBitmapInfo->bmiHeader.biSizeImage = 0;
m_pBitmapInfo->bmiHeader.biXPelsPerMeter = 0;
m_pBitmapInfo->bmiHeader.biYPelsPerMeter = 0;
m_pBitmapInfo->bmiHeader.biClrUsed = 256;
m_pBitmapInfo->bmiHeader.biClrImportant = 0;
int i;
for ( i = 0; i < 256; i++ )
{
m_pBitmapInfo->bmiColors[i].rgbBlue = i;
m_pBitmapInfo->bmiColors[i].rgbGreen = i;
m_pBitmapInfo->bmiColors[i].rgbRed = i;
m_pBitmapInfo->bmiColors[i].rgbReserved = 0;
}
// Stretch pixels out to screen
StretchDIBits(hdc,
xCord,yCord,ImX,ImY,
0,0,ImX,ImY,
img, //------->>> Pointer to array of bits, a CChildView variable member.
m_pBitmapInfo,
DIB_RGB_COLORS,
SRCCOPY);
|
|
|
|
|
Looks OK to me, although I'd set up the BitmapInfo record outside the paint processing. If ImX, ImY change between calls you can set just them. This would get that nasty for loop out of there!
Anyhow, back to the flicker - the other possibility is that your WindowClass (that's class as in WNDCLASSEX) has a background brush defined. In this case I seem to recall that BeginPaint will erase the background without raising a WM_ERASEBKGND message.
|
|
|
|
|
hii...
how can i get a bitmap from a window and use it in my application?
regards,
kedar.
|
|
|
|
|
Hello,
I am working with win32 serial communication in VC++. My application communicates with a Control Panel hardware device which is similar to a Keyboard. It has various keys/buttons (”0-9 digit keys, A-Y alphabet keys and F1,F2,F3 keys”) on it , and is connected through the serial port of the PC. My application has to capture which key/button is pressed and released on the Control Panel board. When a key/button is pressed or released on the Control Panel board, my application should post the appropriate message to the main handling application which is responsible for processing the Key Down and Key Up messages received from Control Panel board.
My application can find out the keys pressed or released on the Control Panel board. Now I need to post WM_KEYDOWN and WM_KEYUP messages when keys are pressed or released to the handling main application. But I should find a way to tell the handling main application, that the posted WM_KEYUP or WM_KEYDOWN message is from the Control Panel board and not from the Key board. The handling main application should be able to distinguish between the WM_KEYDOWN and WM_KEYUP messages from the Keyboard and the Control Panel board.
When I went through the MSDN,
http://msdn.microsoft.com/library/d.../wm_keydown.asp
I found that there is a field “Scan Code” in the lParam which is of use. I want to use this field to differentiate between messages of control panel buttons and keyboard keys.
But I need some more information on this:
1. Are scan codes for keyboards standardized?
2. If scan codes are standardized, where can I get a list of the unused scan code range so that I may use them for the control panel?
3. How can I set these scan codes while posting the messages trough code?
I am trying to search on google.com site for this information, but couldn’t get any useful link. I have never worked with this type of application and hence am unable to proceed further.
Can anyone please help me in this? It would be of great help to me if you can give me some links or information on this area?
Thanks in anticipation of information.
Madhavi.
Madhavi
|
|
|
|
|
Why are you using WM_KEYUP and WM_KEYDOWN? If you want to distinguish your keys from those from the system why not just use messages such as:
#define WM_CONTROLPANEL_KEYUP WM_APP+0
#define WM_CONTROLPANEL_KEYDOWN WM_APP+1
|
|
|
|
|
I would tend to agree.
This statement The handling main application should be able to distinguish between the WM_KEYDOWN and WM_KEYUP messages from the Keyboard and the Control Panel board. already seems to imply that the application MUST see something different than regular 'keystrokes' from the panel.
If the applciation is not going to process event fromt he control panel as regular keystrokes, then the application must be written to be specifically aware of the control panel events, as a result, you are free to define whatever interface you desire between your application and the control panel.
It might make sens to follow something similar to the WM_KEY??? interfaces, so as to make your interface familiar to other developers.
If you want your interface to be useful to other programmers, I would not use the WM_APP+??? messages in this case, since they already might be in use. You could use registered Widnow Messages if your system is in a DLL or static link library and communicates by sending window messages.
|
|
|
|
|
Hi I am dinesh,
I want to produce the report using EXCEL sheet, I have my data in some variables. I am using VC++ for my project.
can any one help me by giving hint, how to link VC++ with MS-Excel.
Dinesh Salvi.
|
|
|
|
|
Hello, you'd better go to microsoft.com and look for Office Automatization. There are some very nice articles in C++. but i don't remember where is it exactly
|
|
|
|
|
Check out MSDN article Q178749.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Okay, I have my app but I need to now incorporate transmitting and receiving on the serial port. I can communicate via the serial port by hand (send statement then receive statement) but I want to thread-ify it. I'm thinking about at least threading the receiver at least, that way I can take an endless loop (or ends when the port is closed) and then simply listen for a character, store it and repeat. I think I can do that in a class derived from CWinThread. I need a FIFO-type buffer to store the characters that are read from the serial port from one end and transfer the data to my app, in a pipeline from the thread to my app.
First, what would be the best way to transfer data? All I can think of is deriving a class from CObject to hold the data, probably one byte at a time so it won't be waiting indefinitely for data that might not come and then use CObList and use the AddHead() and RemoveTail() to enforce the FIFO-style and the list will hold the data for me. I did this before because I needed to store run-length encoded bitmap information so I know how to do all of that.
Second, how do I pass something like that from my app to the thread class because the example I found uses AfxBeginThread to run the thread and there's no way to pass an argument, or none that I can see. Maybe create a function in my app that returns a pointer to the CObList. When the threads InitInstance runs, it can read the pointer, read the serial data and add that data to the list at the head?
Thanks in advance for your insight, Nathan.
|
|
|
|
|
I just went ahead and I'm trying to do it anyway, if it works or not. I can pass data through too since I'm using the worker thread, not UI thread type.
|
|
|
|
|
Writing a threaded application that utilizes a single worker thread performing essentially a single task and communicating with a parent thread is not all that difficult.
Multithreading becomes tricky, at least in my opinion, mostly when you start having to use CriticalSections, which can be very subtle in terms of debugging.
But for what you describe, I think you can accomplish it with some fairly simple synchronization tools that are predictable and not so prone to the subtle intermittant errors CriticalSections can cause.
Read up a little on thread synchronization primitives. Each has it's various merits and uses.
Here are some of the families that I think you will find useful in the app you described:
Mutexes/Semaphores are used in combination to provide a reliable way to synchronize threads' read/write access to common data to prevent access violations.
InterlockedIncrement and related Interlocked APIs provide inherently threadsafe and utterly simple to implement methods to toggle a shared boolean, increment/decrement a count variable shared by two threads, etc. For example, a parent thread telling a worker thread to cancel a task is as simple as declare an integer, have the parent increment it to signal a cancel, and have a worker thread check the value periodically.
CreateEvent/PulseEvent provide a way for one thread to start and stop another thread that needs to execute code in a continuous loop, or execute a single task repeatedly, but only after being signaled by the parent.
And so forth.
That should give you plenty of ideas to start with ...
Robert
|
|
|
|
|
I will read up on critical sections, I have used Synchronized functions in Java so I'm aware of the idea of a critical section, in case I need to do it in the future. However, I'm under the presumption that the serial port is bidirectional. In my app, I created a serial port class that handles communication. Both the transmitting and receiving threads have the pointer to the serial port and communicates that way. In this case, I don't see where I'd need synchronization because the two threads can run independantly, am I wrong with this point?
|
|
|
|
|
You might have to synchronize access to your serial port for the ClearCommError and status functions. Some of the port status data is 'clear on read' so you need to be careful of that.
Also, your I/O buffers should be synchronized - your port read thread is writing to a buffer of data received, but your application's main thread should not be simultaneously reading from that buffer at the same time, or you will end up with trouble - your control variables for the buffer will get out of synchonization. Same goes for data the app is writing to the buffer that will be processed by your port's sending thread.
|
|
|
|
|
I need to detect if DirectX or OpenGL application is in fullscreen mode. I dont have much experience with DirectX or OpenGL. Can someone please give me some helpfull hints on a reliable way of doing this.
|
|
|
|
|
In my MSDN (April 2001) the various links(local) are not working properly, most of them have a rectangular square with a dot in it just before the link (such links appear on web pages with missing images) clicking on such a link displays a dialog box with message
A runtime error has occured
Do you wish to debug?
line
Error:Object doesn't support this property or method.
I have reinstalled MSDN, and internet explorer but the problem is still there?
this issue is only with MSDN, web browsing is fine.
how can i fix this?
|
|
|
|
|
I'm doing an application that will allow users to modify 3d cars.
We are currently planning on useing a MFC application but have ran into a few problems. I was wondering if you could give me some advice on this:
I can't really figure out what type of MFC application to use.
Getting all of the widgets and GUI elements to work arn't a problem if we use a MFC Dialog Based application. However the problem with this is we can't seem to get a Menu working in a dialog based application and
Another problem is we need to be able to render real time 3d in directx 9. I was able to make a MFC SDI Based application that integrates the Directx 9.0 API into MFC and can render 3d in real time. But this is a simple black and white screen with no GUI Widgets.
Is there anyway i can combine these two types of MFC applications? Do you know how i could get a menu in MFC Dialog based app? Lastly is it possible to get a MFC SDI window displayed in a MFC Dialog.
Any advice or info would be greatly appreciated.
|
|
|
|
|
Warning! Shameless self-plug ahead!!
I recently published an article here that may help you out: A 3D-Enabled View Base Class for SDI Direct3D Development[^].
It's a CView-derived class specifically for Direct3D rendering in an SDI environment. Since it's designed for SDI apps, you'll have full use of all the MFC widgets, gidgets, and gadgets. It's written to DirectX 8.0 spec, but it's a small class, and only some minor changes would need to be made to convert it use the Direct3D 9.0 interface instead of 8.0.
Bob Ciora
|
|
|
|
|
"I was able to make a MFC SDI Based application that integrates the Directx 9.0 API into MFC and can render 3d in real time. But this is a simple black and white screen with no GUI Widgets."
Thats not the problem. I have a MFC SDI directx window program. The problem is takeing that really basic looking window and wrapping a dialog around it with nice gui features. Do you see my problem? I can do directx in a basic window and i can do nice gui in a dialog window but i can't do both... any ideas?
|
|
|
|
|
Ahh, my apologies. I was under the impression that, although you managed to integrate Direct3D with SDI, but couldn't get any of the other widgets or menus working with that (re: your comment about the simple black and white screen). The goal of the class in the article was to provide a CView-derived base class that you can inherit your own View class from and not have to worry about piecing in the DirectX "guts." The 3D support is built in to provide the basis for an SDI application.
Ok, so to clarify the problem, then....is your goal to have a 3D Dialog-based application? Or to have both a window and a dialog rendering 3D at the same time?
For the dialog, this may work (I'm going to try it out myself to check it). How about adding an empty control that encompasses the area within the dialog in which you want to render the 3D? The control is there only as an "anchor" to provide a window to attach Direct3D, since you need an HWND to initialize Direct3D. You can use a simple "static text" control. I'm thinking that you may have to configure it as "transparent" under the control's "Properties".
In your OnInitDialog, then, you can access the control with GetDlgItem. This returns the generic CWnd pointer for the "anchor" item. You can then use the HWND from that control to initialize DirectX within the Dialog. From there on, you should be able to do all of your rendering and presentation.
Also, you mentioned trouble with the Dialog's menus. What sort of trouble were you having? The statement is a bit hazy 
Just bouncing ideas 
Bob Ciora
|
|
|
|
|
Ok, here's how I got this to work in the dialog:
1. As I mentioned, create some dummy control, a static text box, for example. Size this control within the dialog editor to the place where you want the 3D rendering to occur. Give it an ID that you can remember. For demo purpose, I used IDC_3DANCHOR. In the example below, I used a Static Text control so I can display errors if 3D initialization fails.
2. Declare a CWnd as a member variable of your dialog, e.g. CWnd m_wnd3D (as used in the examples below). This is the actual window to which 3D will be rendered.
3. In OnInitDialog, do the following (after the call to CDialog::OnInitDialog):
CWnd * pAnchor = GetDlgItem(IDC_3DANCHOR);
RECT rectAnchor;
pAnchor->GetWindowRect(&rectAnchor);
ScreenToClient(&rectAnchor);
if( !m_wnd3D.Create( NULL, "", WS_VISIBLE, rectAnchor,
this, ID_3DWINDOW, NULL ) )
{
pAnchor->SetWindowText("Failed creating anchor window");
}
Note that you'll have to explicitly define ID_3DWINDOW in your resource file. But that's easy enough. The Create call will build your (future) rendering window, and position it within the dialog exactly over the Control that you're using as the anchor (IDC_3DANCHOR in this case). Passing this as the fifth parameter makes the window a child of the dialog.
4. After that, do the normal 3D initialization...get the IDirect3D interface, get the desktop format from the current display mode, and use that to create the device:
HRESULT hResult =
m_pDirect3D->GetAdapterDisplayMode(0, &m_d3dDisplayMode);
if( hResult != S_OK )
{
pAnchor->SetWindowText("Failed getting adapter display mode");
return TRUE;
}
memset(&m_d3dPresentParams, 0, sizeof(D3DPRESENT_PARAMETERS));
m_d3dPresentParams.Windowed = TRUE;
m_d3dPresentParams.hDeviceWindow = m_wnd3D;
m_d3dPresentParams.BackBufferFormat = m_d3dDisplayMode.Format;
m_d3dPresentParams.SwapEffect = D3DSWAPEFFECT_COPY_VSYNC;
m_d3dPresentParams.EnableAutoDepthStencil = TRUE;
m_d3dPresentParams.AutoDepthStencilFormat = D3DFMT_D16;
hResult = m_pDirect3D->CreateDevice(
0, D3DDEVTYPE_HAL,
m_wnd3D,
D3DCREATE_HARDWARE_VERTEXPROCESSING,
&m_d3dPresentParams,
&m_p3DDevice );
if( hResult != S_OK )
{
pAnchor->SetWindowText("Failed creating 3D Device");
return TRUE;
}
5. If this was all successful, then the final step is to make sure that the original control you used as an anchor remains hidden:
pAnchor->ShowWindow(SW_HIDE);
6. OnPaint, then, is where you'd perform all of your rendering.
You'll probably want to consider adding OnSize handling in the event that the dialog gets resized, etc. etc.
But this sequence works just fine. In fact, if you know exactly where you want to put your 3D mini-view within the dialog, you don't really need the "anchor" control. I just included it since it's easier to manipulate its size in the dialog editor and just use the GetWindowRect call.
Oh, one other issue....if you're rendering to a Dialog and a View at the same time, you may want to look into Swap Chains. Just more fun Direct3D reading
Hope it helps!
Bob Ciora
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
