C / C++ / MFC

Re: Question regarding DirectX

6-Aug-07 15:40

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++
Java | [Coffee]

godspeed1237-Aug-07 4:49

godspeed123

7-Aug-07 4:49

I created a SDI application in MFC and passed in a viewclass's hwnd.

Is this not correct.

Thanks for the help

Re: Question regarding DirectX

Mark Salsbery7-Aug-07 5:04

7-Aug-07 5:04

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++
Java | [Coffee]

Setting CComboBox Height

WayneK1006-Aug-07 12:41

WayneK100

6-Aug-07 12:41

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

Mark Salsbery6-Aug-07 13:35

6-Aug-07 13:35

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++
Java | [Coffee]

WayneK1006-Aug-07 14:06

WayneK100

6-Aug-07 14:06

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

Mark Salsbery6-Aug-07 14:14

6-Aug-07 14:14

WayneK100 wrote:
Are you using 2005?

Yes, with SP1.

I tried it before posting Smile | :)

For me, the hollow grapples can't be used. The solid grapples are usable.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Extracting binary resources -- PNG and Bitmap

Anurag Gandhi6-Aug-07 20:18

Anurag Gandhi

6-Aug-07 20:18

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; //drop height;
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;
}

Anurag Gandhi.
http://www.softgandhi.co.nr
Life is a computer program and every one is the programmer of his own life.

Torus_XL6-Aug-07 9:37

6-Aug-07 9:37

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)
  {
    //Number of bytes is not in a multiple of 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 D'Oh! | :doh:

)

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...

Mark Salsbery6-Aug-07 9:52

6-Aug-07 9:52

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++
Java | [Coffee]

Torus_XL6-Aug-07 10:10

6-Aug-07 10:10

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 Confused | :confused:

How can I access the colortable and write that data?

Thanks!

Mark Salsbery6-Aug-07 13:28

6-Aug-07 13:28

biSizeImage is already multiplied by the stride/bitcount.

I'm guessing making it overly large is allowing the color table to be written too Smile | :)

Here's updated code showing an example of color table handling:

  HRSRC resourceInfo;
  HGLOBAL loadedResourceHandle;
  HINSTANCE instanceHandle;
  BITMAPFILEHEADER bitmapFileHeader;
  LPBITMAPINFOHEADER lpBitmapInfoHdr;
//  UINT bitsPerPixel;
//  UINT extra;
  CFile file;

  instanceHandle = ::AfxGetInstanceHandle();
  resourceInfo = ::FindResource(instanceHandle, MAKEINTRESOURCE(IDB_BITMAP2), RT_BITMAP);
  loadedResourceHandle = ::LoadResource(instanceHandle, resourceInfo);
  lpBitmapInfoHdr = (LPBITMAPINFOHEADER)::LockResource(loadedResourceHandle);

  DWORD BitmapSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER);

  if (lpBitmapInfoHdr->biBitCount == 24)
  {
  }
  else if (lpBitmapInfoHdr->biBitCount <= 8)
  {
      if (lpBitmapInfoHdr->biClrUsed)
          BitmapSize += (lpBitmapInfoHdr->biClrUsed * sizeof(RGBQUAD));
      else
          BitmapSize += ((1 << lpBitmapInfoHdr->biBitCount) * sizeof(RGBQUAD));
  }
  else // 16 or 32 bit bitmap
  {
      if (lpBitmapInfoHdr->biCompression == BI_BITFIELDS)
          BitmapSize += (sizeof(DWORD) * 3);
  }

  if (lpBitmapInfoHdr->biSizeImage == 0)
      lpBitmapInfoHdr->biSizeImage = (((lpBitmapInfoHdr->biWidth * 
                                          (long)lpBitmapInfoHdr->biBitCount + 31L) & (~31L)) / 8L) * 
                                                                          abs(lpBitmapInfoHdr->biHeight);

  bitmapFileHeader.bfOffBits = BitmapSize;
  bitmapFileHeader.bfSize = BitmapSize + lpBitmapInfoHdr->biSizeImage;
  bitmapFileHeader.bfType = 0x4d42;
  bitmapFileHeader.bfReserved1 = 0;
  bitmapFileHeader.bfReserved2 = 0;

  file.Open(resourceFileDir, CFile::modeCreate | CFile::modeWrite | CFile::shareDenyWrite);
  file.Write(&bitmapFileHeader, sizeof(bitmapFileHeader));
  file.Write(lpBitmapInfoHdr, bitmapFileHeader.bfSize - sizeof(bitmapFileHeader));
  file.Close();

I also changed the file object to a CFile.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Torus_XL7-Aug-07 8:10

7-Aug-07 8:10

Awesome, thanks for this. There's a lot of good stuff here that I didn't know about, like with the compression.

Torus_XL6-Aug-07 11:04

Win32: Writing a new line of text? [modified]

6-Aug-07 11:04

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 Smile | :)

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.

deostroll6-Aug-07 9:33

deostroll

6-Aug-07 9:33

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 />
/*  Declare Windows procedure  */<br />
LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM);<br />
<br />
/* debug function  */<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 />
    //...             <br />
    //purposely omitted<br />
    //...<br />
     debug("End Program");<br />
     return messages.wParam;<br />
   <br />
}<br />
<br />
<br />
/*  This function is called by the Windows function DispatchMessage()  */<br />
<br />
LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)<br />
{<br />
    //Message handling code - purposefully omitted<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 />
        //MessageBox(0,"File is opened for writing","File opened",MB_OK | MB_ICONINFORMATION);<br />
        SetFilePointer(h,0,&k,FILE_END);<br />
        //SetFilePosition(h, 0, 0, FILE_END);<br />
        //SetEndOfFile(h);<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

Re: Win32: Writing a new line of text?

Wes Aday6-Aug-07 9:52

Wes Aday

6-Aug-07 9:52

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

Re: Win32: Writing a new line of text?

Nemanja Trifunovic6-Aug-07 10:03

Nemanja Trifunovic

6-Aug-07 10:03

Wes Aday wrote:
Have you tried "This is a test\n\r"?

You mean "\r\n" Smile | :)

Programming Blog
utf8-cpp

Re: Win32: Writing a new line of text?

deostroll7-Aug-07 19:57

deostroll

7-Aug-07 19:57

But why is the value of k zero? LONG k = 0;

CSocket stops receiving

Trooper_IL6-Aug-07 8:54

Trooper_IL

6-Aug-07 8:54

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.

led mike6-Aug-07 9:13

led mike

6-Aug-07 9:13

Does the error occur for any of the unit tests?

What sort of coverage do your unit tests supply?

Mark Salsbery6-Aug-07 9:40

6-Aug-07 9:40

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++
Java | [Coffee]

Trooper_IL7-Aug-07 3:09

Trooper_IL

7-Aug-07 3:09

I am receiving the number bytes I'm expecting, first by receiving a buffer size parameter,and then the rest of the message.

Mark Salsbery7-Aug-07 4:57

7-Aug-07 4:57

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++
Java | [Coffee]