C / C++ / MFC Discussion Boards

George_George18-Feb-08 16:48

18-Feb-08 16:48

Hello everyone,

Here are two conflicting documents from MSDN. About whether linker will modify code generated by compiler. I quote both of them here.

Document (1) mentioned linker can not modify any code generated by compiler, but document (2) mentioned linker will replace address code generated by compiler during fixup process.

Which one is correct?

1.

http://blogs.msdn.com/oldnewthing/archive/2006/07/21/673830.aspx

--------------------
But the linker can't rewrite the code generated by the compiler.
--------------------

2.

http://www.microsoft.com/msj/0797/hood0797.aspx

--------------------
Consider a call to a function named Foo in C++:

//...
Foo();
//...

The exact bytes emitted from a 32-bit C++ compiler will be this:

E8 00 00 00 00

The 0xE8 is the CALL instruction opcode. The next DWORD should contain the offset to the Foo function (relative to the CALL instruction). It's pretty clear that Foo probably isn't zero bytes away from the CALL instruction. Simply put, this code wouldn't work as expected if you were to execute it. The code is broken, and needs to be fixed up. In the above example, the linker needs to replace the DWORD following the CALL opcode with the correct address of Foo.
--------------------

thanks in advance,
George

Re: linker

David Crow18-Feb-08 17:13

David Crow

18-Feb-08 17:13

George_George wrote:
Which one is correct?

The non-wrong one.

The linker does not modifiy your code. Moving code around in memory (i.e, rebasing) does not change the code itself. Both statements are correct.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Re: linker

George_George18-Feb-08 18:49

George_George

18-Feb-08 18:49

Thanks DavidCrow,

You mean both of them are correct? But they are of different options, the point of the first one means linker can not modify the code produced by compiler, but the 2nd one means linker modifies the code produced by compiler.

regards,
George

Re: linker

David Crow19-Feb-08 2:27

David Crow

19-Feb-08 2:27

George_George wrote:
You mean both of them are correct?

Is that what you inferred from what I said? Just take the red pill and watch out for stray rabbits.

Re: linker

George_George19-Feb-08 14:50

George_George

19-Feb-08 14:50

This one,

http://www.codeproject.com/script/Forums/View.aspx?fid=1647&msg=2432489[^]

It is appreciated if you could comment, if you think the linker will not modify code generated by the compiler, how could the compiler generate the assembly code (or binary code) for statement like

func1();

regards,
George

Re: linker

Stephen Hewitt18-Feb-08 17:55

Stephen Hewitt

18-Feb-08 17:55

The second is correct.

Steve

Re: linker

George_George18-Feb-08 18:50

George_George

18-Feb-08 18:50

Thanks Stephen,

Your confirmation makes me more confident. Smile | :)

regards,
George

Nasty runtime error with WM_PAINT in native GUI framework.

edu.net18-Feb-08 14:38

edu.net

18-Feb-08 14:38

I have done the basics in creating a simple GUI framework. Set the WNDCLASSEX with lpfnWndProc pointing to a static member function of my base window class. Calling CreateWindowEx with the appropriate parameters returns a valid HWND. This works well for the main form. Its drawn properly, no problems.

When I create a child window and initialize it as mentioned it runs ok; the global WNDPROC routes all messages via the SetWindowLong/GetWindowLong to the window and they are handled ok. ALL BUT THE WM_PAINT MESSAGE. The application crashes with a runtime error. The same occurs with WM_NCPAINT.

WM_GETMINMAXINFO, WM_CREATE, WM_NCCREATE etc are all working well, except the paint messages.

Here's the global WNDPROC.

<br />
LRESULT CALLBACK<br />
WinControl::GlobalWndProc(HWND pHWnd, UINT pMsg, WPARAM wParam, LPARAM lParam)<br />
{<br />
  LRESULT nResult = 0;<br />
<br />
  WinControl * nControl = NULL;<br />
<br />
  MSG nMsg = { 0 };<br />
<br />
  WinCriticalSection nLock;<br />
<br />
  LPCREATESTRUCT nLPStruct = { 0 };<br />
<br />
  nLock.Lock();<br />
<br />
  nControl = reinterpret_cast<WinControl *>(::GetWindowLong(pHWnd, GWL_USERDATA));<br />
<br />
  if((nControl == NULL) && (pMsg == WM_NCCREATE))<br />
  {<br />
    nLPStruct = reinterpret_cast<LPCREATESTRUCT>(lParam);<br />
<br />
    nControl = reinterpret_cast<WinControl *>(nLPStruct->lpCreateParams);<br />
<br />
    ::SetWindowLong(pHWnd, GWL_USERDATA, (LONG)nControl);<br />
  }<br />
<br />
  if(nControl == NULL<br />
  {<br />
    nResult = ::DefWindowProc(pHWnd, pMsg, wParam, lParam);<br />
  }<br />
  else<br />
  {<br />
    nMsg.hwnd = pHWnd;<br />
<br />
    nMsg.lParam = lParam;<br />
<br />
    nMsg.wParam = wParam;<br />
<br />
    nMsg.message = pMsg;<br />
<br />
    /////////// THIS PART FAILS WHEN ITS WM_PAINT OR WM_NCPAINT ON THE  CHILD WINDOW<br />
/////////// (WS_CHILD | WS_VISIBLE)<br />
    nResult = nControl->WndProc(&nMsg);<br />
<br />
    nControl = NULL;<br />
  }<br />
<br />
  nLock.Unlock();<br />
<br />
  return nResult;<br />
}<br />

<h>Hope is the remainder of the of the number of times you thought you wouldn't make it divided by infinity. - e.m

Re: Nasty runtime error with WM_PAINT in native GUI framework

Joe Woodbury18-Feb-08 16:05

Joe Woodbury

18-Feb-08 16:05

You're using some third party library that likely has bugs.

You do not need, nor should you, use a critical section in your main procedure.

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

modified on Monday, February 18, 2008 10:12 PM

Re: Nasty runtime error with WM_PAINT in native GUI framework

edu.net18-Feb-08 22:00

edu.net

18-Feb-08 22:00

Joe Woodbury wrote:
You're using some third party library that likely has bugs.

My project has no external dependencies other than those windows provided. Am trying to build a GUI framework from the ground up.

Joe Woodbury wrote:
You do not need, nor should you, use a critical section in your main procedure.

You're right there, had not done enough reading.

This bug is starting to get to me.

<h>Hope is the remainder of the of the number of times you thought you wouldn't make it divided by infinity. - e.m

Re: Nasty runtime error with WM_PAINT in native GUI framework.

Mark Salsbery19-Feb-08 8:33

Mark Salsbery

19-Feb-08 8:33

I don't see any problems in the code you've shown.

Where is it crashing? Stepping into the nControl->WndProc(&nMsg) call
on a WM_PAINT message - where does it crash?

Mark

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

Re: Nasty runtime error with WM_PAINT in native GUI framework - WORKAROUND FOUND

edu.net19-Feb-08 13:59

edu.net

19-Feb-08 13:59

I stepped through the

nControl->WndProc(Msg & nMsg)

and found that nControl was not a valid pointer. This was irregular because it only happened when the WM_PAINT and the WM_NCPAINT were sent to the window.

Here's the history:

I have a class, WinControl that is responsible for wrapping methods related to manipulation of a windows control. It has a RegisterWindowClass method that creates the WNDCLASSEX passing it to the the native RegisterClassEx API function. The lpfnWndProc is set to point to a public static GlobalWndProc member function of the WinControl class.

Upon window creation using CreateWindowEx all windows messages are passed to the GlobalWndProc function. In here the HWND sent by windows is associated with the WinControl being created (when the WM_NCCREATE message is received):

SetWindowLong(theHWND, GWL_USERDATA, pointerToTheWinControlObtainedFromTheLPARAM)

On subsequent system messages, the WinControl mapping to the HWND supplied by the system is retrieved by:

GetWindowLong(theHWND, GWL_USERDATA)

Once retrieved the message is passed to a protected WndProc method in the WinControl class where using the this pointer, the window is able to consume it appropriately.

The problem was arising because the retrieval of the WinControl was failing, specifically during the WM_PAINT message.

After lots of cursing, gnashing of teeth, the following workaround seems to have settled the issue:

1. Associate the WinControl's HWND using:

static VOID 
    AssociateControlWithHWnd(IN CONST WinControl * pControl,
                             IN CONST HWND pHWnd)
    {
      if(pHWnd != NULL)
      {
        SetWindowLongPtr (pHWnd, 0, 0);

        SetWindowLongPtr (pHWnd, 8, (LONG_PTR) pControl);

        SetWindowLongPtr (pHWnd, GWLP_USERDATA, improbableWindowNumber);
      }
    }

2. Retrieve the WinControl's HWND using:

static WinControl * 
    GetControlFromHWnd(HWND pHWnd)
    {
      if((pHWnd != NULL) && (::GetWindowLong(pHWnd, GWLP_USERDATA) == improbableWindowNumber))
      {
        return reinterpret_cast<WinControl *>GetWindowLong(pHWnd, 8));
      }

      return NULL;
    }

where improbableWindowNumber = 0xf965aa01.

I bumped onto JUCE and after a tweaking a thing or two, with the above code, the nControl was retrieved successfully and all messages were routed without any problems.

And that is half a day of my life I will never get back.

Thanks for the concern.

<h>Hope is the remainder of the of the number of times you thought you wouldn't make it divided by infinity. - e.m

please explain how it works

ashwiny18-Feb-08 14:14

ashwiny

18-Feb-08 14:14

could anyone tell me briefly how this code is working?please help me.

// nonrec_t.spc -- test program for non-recursive filter design <br />
<br />
 <br />
<br />
#include "tools.h"<br />
<br />
#include "ltisys.h"<br />
<br />
#include "nonrec.h"<br />
<br />
 <br />
<br />
int main()<br />
<br />
{<br />
<br />
       Graph gr(3,2,"Non-Recursive Filter Design");<br />
<br />
 <br />
<br />
       // calculate low-pass filter and plot<br />
<br />
       LTISystem lp = NRLowPass(0.1,63);<br />
<br />
       lp.a.plot(gr,1,"Low-pass at 0.1","Samples","Amp");<br />
<br />
 <br />
<br />
       // calculate frequency response and plot<br />
<br />
       Spectrum lpf(500,1000);<br />
<br />
       for (int i=0;i<500;i++) lpf[i] = lp.response(i/1000.0);<br />
<br />
       lpf.plotLogMag(gr,2,"Frequency Response");<br />
<br />
 <br />
<br />
       // calculate high-pass filter and plot<br />
<br />
       LTISystem hp = NRHighPass(0.4,63);<br />
<br />
       hp.a.plot(gr,3,"High-pass at 0.4","Samples","Amp");<br />
<br />
 <br />
<br />
       // calculate frequency response and plot<br />
<br />
       Spectrum hpf(500,1000);<br />
<br />
       for (int i=0;i<500;i++)<br />
<br />
              hpf[i] = hp.response(i/1000.0);<br />
<br />
       hpf.plotLogMag(gr,4,"Frequency Response");<br />
<br />
 <br />
<br />
       // calculate band-pass filter and plot<br />
<br />
       LTISystem bp = NRBandPass(0.2,0.3,63);<br />
<br />
       bp.a.plot(gr,5,"Band-pass at 0.2-0.3","Samples","Amp");<br />
<br />
 <br />
<br />
       // calculate frequency response and plot<br />
<br />
       Spectrum bpf(500,1000);<br />
<br />
       for (int i=0;i<500;i++) bpf[i] = bp.response(i/1000.0);<br />
<br />
       bpf.plotLogMag(gr,6,"Frequency Response");<br />
<br />
       <br />
<br />
       gr.close();<br />
<br />
}<br />

// kaiser_t.cpp -- test program for Kaiser window design <br />
<br />
 <br />
<br />
#include "tools.h"<br />
<br />
#include "ltisys.h"<br />
<br />
#include "nonrec.h"<br />
<br />
#include "kaiser.h"<br />
<br />
 <br />
<br />
const int MAXKAISERWIN=256; // maximum window length<br />
<br />
 <br />
<br />
// Create non-recursive low-pass filter using Kaiser window<br />
<br />
LTISystem KaiserLowPass(<br />
<br />
       double freq,         // corner freq <br />
<br />
                           //  (fraction of sampling rate)<br />
<br />
       double ripple,       // allowed ripple (dB)<br />
<br />
       double twidth        // transition width <br />
<br />
                           //  (fraction of sampling rate) }<br />
<br />
       )                    // returns LTI System<br />
<br />
{<br />
<br />
       int    i;<br />
<br />
 <br />
<br />
       // get (half-)Kaiser window<br />
<br />
       Waveform kwin = Kaiser(ripple,twidth,MAXKAISERWIN);<br />
<br />
       int nhalf = kwin.count()-1;<br />
<br />
 <br />
<br />
       // generate one half of coefficients from <br />
<br />
       //     windowed sinc() function<br />
<br />
       double omega = 2*PI*freq;<br />
<br />
       for (i=0;i<=nhalf;i++)<br />
<br />
              kwin[i+1] *= omega*sinc(i*omega)/PI;<br />
<br />
 <br />
<br />
       // copy into LTI System<br />
<br />
       LTISystem lpfilt(2*nhalf,0);<br />
<br />
       lpfilt.a[nhalf] = kwin[1];<br />
<br />
       for (i=1;i<=nhalf;i++) {<br />
<br />
              lpfilt.a[nhalf-i] = kwin[i+1];<br />
<br />
              lpfilt.a[nhalf+i] = kwin[i+1];<br />
<br />
       }<br />
<br />
 <br />
<br />
       return lpfilt;<br />
<br />
}<br />
 <br />
<br />
<br />
<br />
 <br />
<br />
int main()<br />
<br />
{<br />
<br />
       int    i;<br />
<br />
 <br />
<br />
       // initialise graphics<br />
<br />
       Graph gr (2,2,"Kaiser Window Design");<br />
<br />
 <br />
<br />
       // plot Kaiser window 1<br />
<br />
       Waveform kwv1 = Kaiser(40.0,0.005,MAXKAISERWIN);<br />
<br />
       kwv1.plot(gr,1,"Kaiser (40dB/0.005)");<br />
<br />
 <br />
<br />
       // calculate and plot frequency response<br />
<br />
       LTISystem lp1 = KaiserLowPass(0.1,40.0,0.005);<br />
<br />
       Spectrum lpf1(500,1000);<br />
<br />
       for (i=0;i<500;i++) lpf1[i] = lp1.response(i/1000.0);<br />
<br />
       lpf1.plotLogMag(gr,2,"Frequency Response");<br />
<br />
 <br />
<br />
       // plot Kaiser window 2<br />
<br />
       Waveform kwv2 = Kaiser(80.0,0.01,MAXKAISERWIN);<br />
<br />
       kwv2.plot(gr,3,"Kaiser (80dB/0.01)");<br />
<br />
 <br />
<br />
       // calculate and plot frequency response<br />
<br />
       LTISystem lp2 = KaiserLowPass(0.1,80.0,0.01);<br />
<br />
       Spectrum lpf2(500,1000);<br />
<br />
       for (i=0;i<500;i++) lpf2[i] = lp2.response(i/1000.0);<br />
<br />
       lpf2.plotLogMag(gr,4,"Frequency Response");<br />
<br />
 <br />
<br />
       gr.close();<br />
<br />
}<br />
 <br />

Re: please explain how it works

Joe Woodbury18-Feb-08 16:07

Joe Woodbury

18-Feb-08 16:07

Try reading the article you copied this from: http://www.phon.ucl.ac.uk/courses/spsci/dsp/lpc.html[^]

If you don't understand digital signal processing, learn that first.

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

Re: please explain how it works

David Crow18-Feb-08 17:16

David Crow

18-Feb-08 17:16

ashwiny wrote:
could anyone tell me briefly how this code is working?

Which part exactly?

Bitmaps Painting

Bram van Kampen18-Feb-08 13:21

Bram van Kampen

18-Feb-08 13:21

Hi,

I'm trying to paint a Bitmap in my dialog. Got as far as:

CWnd* pWnd =GetDlgItem(IDC_LOGO);
if(pWnd){
CDC* pDC=pWnd->GetDC();
CBitmap Bmp;
Bmp.LoadBitmap(IDB_LOGO);
pDC->SelectObject(&Bmp);

// What Next to Paint it

}

My Bitmap painting skills are very seldomly excersised, and got a bit rusty as a result.

Bram van Kampen

Re: Bitmaps Painting

Sameerkumar Namdeo18-Feb-08 15:50

Sameerkumar Namdeo

18-Feb-08 15:50

create a compatible dc using pDC.
select the Bmp in this compatible dc.
at last pDC->Bitblt(......compatible dc);

Re: Bitmaps Painting

Rajkumar R18-Feb-08 19:17

Rajkumar R

18-Feb-08 19:17

ccpptrain is right,

using CImage is much simple

CImage img;
img.LoadFromResource(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDB_LOGO));
img.BitBlt((HDC)pDC, 0, 0);

Re: Bitmaps Painting

Hamid_RT18-Feb-08 19:43

Hamid_RT

18-Feb-08 19:43

A good article for you Displaying Bitmap with Scrolling[^]. Smile | :)

Re: Bitmaps Painting

Bram van Kampen20-Feb-08 13:57

Bram van Kampen

20-Feb-08 13:57

Thanx

I Never Knew that, but you can actually import a static Bitmap Resource direct into MS5++.

Actually that was all I was looking for.

Regards

Laugh | :laugh:

Bram van Kampen

An interesting problem

tibiz18-Feb-08 12:07

tibiz

18-Feb-08 12:07

I create a thread in a very simple app, that way:

<br />
HWND hWnd = CreateWindow(...);<br />
<br />
DWORD _tid;<br />
if((CreateThread(NULL, 0, msgprocessing, hWnd, 0, &_tid)) == NULL) {<br />
   error();<br />
}<br />
// hWnd is the parameter for thread<br />

I need tu run message processing in the thread to catch msg's for hWnd window, but it won't work. Everything else is coded correctly. Any ideas why Confused | :confused:

Re: An interesting problem

BadKarma18-Feb-08 12:30

BadKarma

18-Feb-08 12:30

Hi,

have you tried to create the window in the thread that needs to catch the messages?
This should work.

codito ergo sum

Re: An interesting problem

Prasanth M V18-Feb-08 17:30

Prasanth M V

18-Feb-08 17:30

Hi,

U can create window in thread. The message of that window will pass though the PreTransalte and MessageLoop of the application .

If needed i hope u can implement you own message loop(in the thread itself) after the creation of window.
I do not know if the implementation of message loop in the thread will causue any problem withe the main message loop of the application.

Prasanth Vijay

Re: An interesting problem

Prasanth M V18-Feb-08 17:36

Prasanth M V

18-Feb-08 17:36

U can use PeekMessage() message for implementing the message catching loop.
See the help in MSDN.
If u have time, Plz have look on CWInApp::Run() or CWinThread::Run() in the MFC message implementation. This will give very good idea on the messaeg loop implemenattion.

Thanks
Prasanth Vijay

Re: An interesting problem

tibiz18-Feb-08 23:48

tibiz

18-Feb-08 23:48

I used the PeekMessage and tried to create the window in the secondary thread, but still not working. So I placed the whole code, here (sorry for the comments, they are not in ENG)

tibiZ.net homepage

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.