|
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
|
|
|
|
|
Thanks a ton for the help but i'm stuck on #3
"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."
what exactly will the ID_3DWINDOW be? How do i make one in my resource file?
Also when i say i can't get menus in a dialog box i mean the MFC menu with File,Edit...ect at the top of the screen.
thanks again!
|
|
|
|
|
When you create the dialog in the resource editor, in the Dialog's properties, there's a drop down list to specify a menu resource to add to the dialog. Create the menu you want to use with the dialog in the resource editor, and just use that menu's IDR_xxx code in the Dialog's properties window.
As for creating the ID value for the window, you can do that in the Resources tab of the Workspace pane in Visual Studio. On the outermost folder there, the one with "(your app) Resources", right click on that. A popup menu will appear. Select "Resource Symbols" and you can define a new symbol name there. It will automatically assign a new value for the symbol, so you don't have to worry about which value to use.
Bob Ciora
|
|
|
|
|
Have a look at CDialogBar. It allows you to dock a dialog to a mainframe window and the docking location can be any of the CBRS_TOP family locations. You can also have multiple dialogs docked for example one on the left side and one on top.
I believe there are samples that use it on MSDN.
|
|
|
|
|
That one looks like it might do the trick, too. At least the "dialog" is tied directly more closely to the application in this case.
For this particular problem, if it's DirectX 9, I found this, too:
DirectX AppWizard[^]
Looks like you can create a 3D-enabled dialog app there, too
Bob Ciora
|
|
|
|
|
I'm working with VS studio.net so i'll either have to hunt down a copy of VS 6.0 or keep working with your first idea.
I'm at step 4 and i'm getting the error:
error C2065: 'm_pDirect3D' : undeclared identifier
What include do i need for this? I tried d3d8.h and d3d9.h as i have the Directx 9.0 sdk on the pc.
Also i made a menu in resource view and gave it an id of menu. However when i click on my dialog resource i can't find any sort of drop box or place to include the menu id. I'm useing visual studio.net. Can you be more specific?
Thanks again.
|
|
|
|
|
The m_ variables were defined in the header file for that dialog. Here are the declarations:
LPDIRECT3D8 m_pDirect3D;
D3DDISPLAYMODE m_d3dDisplayMode;
D3DPRESENT_PARAMETERS m_d3dPresentParams;
LPDIRECT3DDEVICE8 m_p3DDevice;
HRESULT m_hDeviceState;
D3DXCOLOR m_cClearColor;
D3DVIEWPORT8 m_Viewport;
CWnd m_wnd3D;
I only have the DirectX 8.0 toolkit, so you'll want to make these be DirectX 9 references (although DX8 stuff should work with DX9).
Bob Ciora
|
|
|
|
|
I inluded "d3dx8.h" and declared your variables in the dialog.h. It compiles ok but when it runs i get the windows xp "report error screen" that says:
"TODO: has encountered a problem and needs to close. We are sorry for the inconvenience."
and the program won't run. Do you think this is because i have the directx9 sdk? or mabye because i'm using .net? In any case i really don't know much about directx i just need this window included in my application so someone can implement it later.
I migt just want up finding a copy of VS studio 6.0 so i can use the directx wizard and make a dialog app. I was really hopeing your steps would work for me any ideas? I have two other questions
#1 I made a menu in resource view and gave it an id of menu. However when i click on my dialog resource i can't find any sort of drop box or place to include the menu id. I'm useing visual studio.net. Can you be more specific?
#2 You told me: "You'll probably want to consider adding OnSize handling in the event that the dialog gets resized, etc. etc." Do you have sample code on how to do this? I would really like my application to have the ability to maximize and re-size.
thanks much!
|
|
|
|
|
I wanna write the app that control CD Player using hot key
and lock some keystrokes by Hook.
Ex: Ctrl + P :Play,Pause, Ctrl + E :Eject/Insert CD....
Can you guide me some steps to begin ?
ThkU...
NewTan
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
