|
Should you wait until the user has finished moving the slider control before sending out its position? If so, respond to the TBN_ENDDRAG notification.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi
I am new with DirectX and I need to get access to a joystick.
So I have written the following code, but I am getting an error when I try to SetCooperativeLevel the return is E_HANDLE. I have checked the sample code and I am doing everything the same, and yet I am getting these error. Can anyone tell me why. I have attached the code:
HRESULT hr;<br />
if ( FAILED( hr = DirectInput8Create( GetModuleHandle(NULL), DIRECTINPUT_VERSION, IID_IDirectInput8, (VOID**) &di, NULL ) ) ) {<br />
return hr;<br />
}<br />
<br />
<br />
if ( FAILED( hr = di->EnumDevices( DI8DEVCLASS_GAMECTRL, enumCallback, this, DIEDFL_ATTACHEDONLY ) ) ) {<br />
return ;<br />
}<br />
<br />
if ( joystick == NULL ) {<br />
return ;<br />
}<br />
if ( FAILED( hr = joystick->SetDataFormat( &c_dfDIJoystick2 ) ) ) {<br />
return ;<br />
}<br />
<br />
if ( FAILED( hr = joystick->SetCooperativeLevel( this->GetSafeHwnd(), DISCL_EXCLUSIVE | DISCL_FOREGROUND ) ) ) {<br />
int test = 0;
return ;<br />
}
|
|
|
|
|
E_HANDLE
"The HWND parameter is not a valid top-level window that belongs to the process"
What window are you calling this from?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I created a SDI application in MFC and passed in a viewclass's hwnd.
Is this not correct.
Thanks for the help
|
|
|
|
|
It should be a top-level window. The main frame window should work.
One way to get it is AfxGetApp()->GetMainWnd()->GetSafeHwnd()
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
The combo box tutorial says you can change the combo box height at edit time by right-clicking on the arrow and resizing the box. I believe that technique referenced Visual Studio 6.0. I haven't found a way to resize it (at edit time) under Visual Studio 2005. Does anyone know a way?
Wayne King
|
|
|
|
|
Click the arrow. The middle grapple on the bottom edge will highlight.
Then you can drag it down with that grapple.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
That doesn't work in Visual Studio 2005, at least not on mine. Are you using 2005? Maybe my IDE configuration is screwed up.
Wayne
|
|
|
|
|
WayneK100 wrote: Are you using 2005?
Yes, with SP1.
I tried it before posting
For me, the hollow grapples can't be used. The solid grapples are usable.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
If you are unable to do in design, You have the option of doing it through coding. Here is the sample:
CRect rect;
rect.top = 1;
rect.bottom = rect.top + 250;
if(!m_ComboBox.Create(WS_CHILD | CBS_DROPDOWNLIST | WS_VISIBLE |
WS_TABSTOP | WS_VSCROLL, rect, &m_comboToolBar, ID_COMBO)) {
TRACE(_T("Failed to create combo-box\n"));
return FALSE;
}
|
|
|
|
|
I am having a problem extracting the binaries of PNG files and extracting Bitmap files to write to disk. I am using http://www.codeproject.com/win32/binaryresources.asp[^] as a rough guide.
The problem with the PNG is that the extracted PNG files are automatically buffered to have a number of bytes equal to a multiple of TCHAR. For example, one PNG resource I have is 251 bytes long, but when extracted it is 255. These 4 extra bytes seem to be making it an unreadable file. Is there any kind of data type that is a pure bit stream, or is there a way to write the TCHAR byte by byte and leave off those extra 4 bytes?
As for the bitmap files, a similar problem occurs. For this I will post some code:
void BitmapResourceToFile(int resourceId, CString dirToWriteTo)
{
HRSRC resourceInfo;
HGLOBAL loadedResourceHandle;
HINSTANCE instanceHandle;
BITMAPFILEHEADER bitmapFileHeader;
LPBITMAPINFOHEADER bitmapInfo;
UINT bitsPerPixel;
UINT numberOfPixelBytes;
UINT extra;
CStdioFile file;
instanceHandle = ::AfxGetInstanceHandle();
resourceInfo = ::FindResource(instanceHandle,MAKEINTRESOURCE(resourceId),RT_BITMAP);
loadedResourceHandle = ::LoadResource(instanceHandle,resourceInfo);
bitmapInfo = (LPBITMAPINFOHEADER)::LockResource(loadedResourceHandle);
numberOfPixelBytes = (lpBitmapInfo->biWidth * lpBitmapInfo->biBitCount)/8;
extra = numberOfPixelBytes % 4;
if(extra != 0 && extra != 4)
{
numberOfPixelBytes += extra;
}<br>
numberOfPixelBytes *= bitmapInfo->biHeight;
bitmapFileHeader.bfType = 0x4d42;
bitsPerPixel = 1 << bitmapInfo->biBitCount;
bitmapFileHeader.bfSize = (DWORD)(sizeof(bitmapFileHeader) + sizeof(bitmapInfo) + numberOfPixelBytes + bitsPerPixel);
bitmapFileHeader.bfReserved1 = 0;
bitmapFileHeader.bfReserved2 = 0;
bitmapFileHeader.bfOffBits = sizeof(bitmapFileHeader) + sizeof(bitmapInfo);
file.Open(resourceFileDir,CFile::modeCreate | CFile::modeWrite);
file.Write(&bitmapFileHeader,sizeof(bitmapFileHeader));
file.Close();
file.Open(resourceFileDir,CFile::modeNoTruncate | CFile::modeWrite);
file.Write(bitmapInfo,sizeof(bitmapInfo) + numberOfPixelBytes + bitsPerPixel);
file.Close();
}
Every bmp file written to disk is not a valid bmp. What am I doing wrong? Is there a better (and correct) way of doing what I am trying to do? If no one knows an answer, are there any good resources on this subject? (MSDN has not been a good resource )
Thanks for any help!
NOTE: I have left out all of my error checking in the above code to make it more readable. The code compiles and runs, it just does not produce valid bmps or pngs. And sorry about the code being squished together. The forum does not seem to want to preserve my line breaks...
|
|
|
|
|
The BITMAPINFOHEADER has a biSizeImage member so you shouldn't have to calculate it yourself.
If you do choose to calculate it you need to set it to your new value.
You haven't allowed for a color table if the bitmap is <= 8 bitsperpixel.
When writing the file, you write the header and close the file.
Then you reopen the file, truncate it (no more header) and write the rest.
That will invalidate it as a BMP file.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hm ok. I set up the file writing to not truncate (I had thought that "modeNoTruncate" would make it append) and it is making valid bmps, but the bmps are random pixels and furthermore, each time I open a single file the pixels change
How can I access the colortable and write that data?
Thanks!
|
|
|
|
|
|
Awesome, thanks for this. There's a lot of good stuff here that I didn't know about, like with the compression.
|
|
|
|
|
Okay, I've solved the bmp problem. What I wasn't doing was taking the image size to be:
bmBitmapInfo->bmiHeader.biSizeImage*(DWORD)(bmBitmapInfo->bmiHeader.biBitCount);
Instead, I was doing my overly complicated size calculation and then adding bytes until it was in multiples of 4. The biSizeImage*Bits per pixel was all I needed
However, I still ahve that problem with the pngs. Anyone? To reiterate, the problem is that the CFile Write function is writing the whole TCHAR even though I don't want to write 4 of the TCHAR bytes.
|
|
|
|
|
Need to create a function that would write some text message (that I send via argument) to a file. It has to be appended, and it has to appear on the next line. (More like how Print command works for vb file handling).
For the present I have been working with this code:
<br />
#include <windows.h><br />
<br />
<br />
LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM);<br />
<br />
<br />
void debug(LPSTR t);<br />
<br />
int WINAPI WinMain (HINSTANCE hThisInstance,<br />
HINSTANCE hPrevInstance,<br />
LPSTR lpszArgument,<br />
int nFunsterStil)<br />
<br />
{ <br />
debug("This is a test\n"); <br />
debug("End Program");<br />
return messages.wParam;<br />
<br />
}<br />
<br />
<br />
<br />
<br />
LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)<br />
{<br />
return 0;<br />
}<br />
<br />
void debug(LPSTR t)<br />
{<br />
DWORD d; <br />
HANDLE h;<br />
LONG k=0;<br />
if ( (h = CreateFile("log.txt", GENERIC_WRITE, 0, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL,0) ) ) <br />
{<br />
SetFilePointer(h,0,&k,FILE_END);<br />
if ( ! WriteFile(h, t, strlen(t), &d, NULL) )<br />
MessageBox(0,"Write failure","Status", MB_OK | MB_ICONERROR); <br />
} <br />
else<br />
MessageBox(0, "Opening failure", "Status", MB_OK | MB_ICONERROR);<br />
<br />
CloseHandle(h); <br />
}<br />
-- modified at 15:41 Monday 6th August, 2007
The only problem is that I get my text file outputted as below:
<br />
This is a test¤End Program<br />
Instead I would want it as
<br />
This is a test<br/>End Program<br />
<br />
-- modified at 15:47 Monday 6th August, 2007
|
|
|
|
|
deostroll wrote: This is a test\n
Have you tried "This is a test\n\r"?
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
The people in the lounge said I should google for the answer to a programming question but I do not know what search engine to use
|
|
|
|
|
Wes Aday wrote: Have you tried "This is a test\n\r"?
You mean "\r\n"
|
|
|
|
|
But why is the value of k zero? LONG k = 0;
|
|
|
|
|
I have a problem which I am finding myself unable to figure out.
I have a fairly simple CSocket-derived class, which does not much beyond overriding OnReceive so that it saves all the received buffer, and then calling a function of a Pointer to a thread class of mine, which does what it will with the buffer.
At the moment I have a server and a client, both of which have a thread for receiving and a thread for sending through these sockets. The general communication type is thus - client sends a request, server processes and sends some sort of a reply. The messages to be sent in-process are delivered through inter-thread messaging.
The problems occurs mainly while debugging, but it can happen while just running the applications - at some point, if a number of request are "fired" rapidly, the connection get messed up in a rather odd way:
Clients sends successfully, then Server receives, does it's processing, goes on to send a reply, the send operation goes without errors, and yet the other side never receives the message. I've traced all the receive calls on my socket class, and not once there was an error.
So basically, everything indicates that the connection is alive, and yet it never goes through in one direction.
The messages are of varied sizes, but when in debug, 2 140-bytes requests and 160-bytes replies kill the communication.
|
|
|
|
|
Does the error occur for any of the unit tests?
What sort of coverage do your unit tests supply?
|
|
|
|
|
Are you receiving just the number of bytes you're expecting or receiving all the bytes sent?
If the latter, are you parsing the bytes into individual "messages" or assuming it's one message and losing the rest?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I am receiving the number bytes I'm expecting, first by receiving a buffer size parameter,and then the rest of the message.
|
|
|
|
|
You mentioned another thread.
OnReceive() occurs on the thread that creates the socket (through a hidden HWND).
Is this your UI thread?
Seems like something's causing you to lose FD_READ notifications from the socket.
I can only guess without seeing the code.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|