Re: about FARPROC* - C / C++ / MFC Discussion Boards

George_George21-Jun-06 17:20

21-Jun-06 17:20

Thank you zouchao1112!

I think it means a function pointer without any input parameters and returns int type, right?

What means CALLBACK?

regards,
George

Re: about FARPROC*

Sarath C21-Jun-06 3:22

Sarath C

21-Jun-06 3:22

Calling conventions demystified[^]

Sa^Rath.

"Do Next Thing..."

Understanding State Pattern in C++

Re: about FARPROC*

George_George21-Jun-06 17:35

George_George

21-Jun-06 17:35

Hi man,

It is a very good article. Actually, I know what means __cdecl, __stdcall or something similar. The problem is that, there seems not enough documents about what means FARPROC -- I can not find related information from this article.

regards,
George

Re: about FARPROC*

David Crow21-Jun-06 3:29

David Crow

21-Jun-06 3:29

George_George wrote:
I can not find detailed descriptions from MSDN.

Did you look in any of the .h files? Set your cursor somewhere in FARPROC and press F12. You may be asked for permission to build the browser information file.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Re: about FARPROC*

George_George21-Jun-06 17:40

George_George

21-Jun-06 17:40

Hi DavidCrow,

I have used Go to Definition function and find that it is a function pointer, which can be pointed to a function without any input parameters and returns int, right?

But in the definition, there is something like FAR and WINAPI. Do you mean what do they mean?

regards,
George

Re: about FARPROC*

David Crow22-Jun-06 2:39

David Crow

22-Jun-06 2:39

George_George wrote:
But in the definition, there is something like FAR and WINAPI. Do you mean what do they mean?

Look them up in the .h files the same way (i.e., F12).

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Re: about FARPROC*

George_George24-Jun-06 2:09

George_George

24-Jun-06 2:09

Thank you DavidCrow!

I have followed your suggestion and I have solved all the problems except what means far and near. For example, in the following code segment of windef.h.

<br />
#define far<br />
#define near<br />
#if (!defined(_MAC)) && ((_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED))<br />
#define pascal __stdcall<br />
#else<br />
#define pascal<br />
#endif<br />

Can you help please?

regards,
George

Re: about FARPROC*

David Crow26-Jun-06 2:44

David Crow

26-Jun-06 2:44

George_George wrote:
...what means far and near.

With 16-bit Windows and its segmented memory model, you had 16-bit near pointers and 32-bit far pointers. A far reference refers to a function or data object (or a pointer to a function or data object) that is in a different segment than the current one. Memory was referenced like:

segment:offset

Accessing code or data with a near reference is much quicker than accessing it with a far reference. When you use a far reference, your program must first find the segment and then find the code or data within that segment. When you use a near reference, your program only needs to find the code or data.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Re: about FARPROC*

George_George27-Jun-06 2:17

George_George

27-Jun-06 2:17

Thank you DavidCrow!

In nowadays, whether memory is still working in the same way?

regards,
George

Re: about FARPROC*

David Crow27-Jun-06 3:15

David Crow

27-Jun-06 3:15

16-bit Windows will always behave in this fashion. 32-bit Windows does not. It uses a simple, 32-bit address.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Re: about FARPROC*

George_George27-Jun-06 3:43

George_George

27-Jun-06 3:43

Thank you DavidCrow!

I think in nowadays, there is no 16-bit Windows. Right?

regards,
George

Re: about FARPROC*

David Crow27-Jun-06 3:48

David Crow

27-Jun-06 3:48

George_George wrote:
I think in nowadays, there is no 16-bit Windows. Right?

How could I possibly know? Whether something exists and whether it is used are two different things.

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Re: about FARPROC*

George_George27-Jun-06 4:14

George_George

27-Jun-06 4:14

Thank you DavidCrow!

A good answer!

regards,
George

Re: about FARPROC*

Sarath C21-Jun-06 3:35

Sarath C

21-Jun-06 3:35

George_George wrote:
I can not find detailed descriptions from MSDN.

It's rubbish... First Search MSDN then Post.

Check the below link and go to an adequate linkSearch Result for Calling Conventions[^]

Sa^Rath.

"Do Next Thing..."

Understanding State Pattern in C++

Re: about FARPROC*

George_George21-Jun-06 17:33

George_George

21-Jun-06 17:33

Hi Sarath,

The link describes something like __stdcall. There is no information about FARPROC.

regards,
George

Re: about FARPROC*

Zac Howland21-Jun-06 3:39

Zac Howland

21-Jun-06 3:39

It is a typedef that, when you boil down all the macros, expands to the following:

typedef int (__stdcall* FARPROC)();

In other words, any function with the following signature could be pointed to by a FARPROC pointer:

int __stdcall f();

To make it portable, you would just remove the __stdcall part of the line. For example, if you want it to work in Linux, define CALLBACK as nothing:

#ifndef CALLBACK<br />
#define CALLBACK<br />
#endif // CALLBACK

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: about FARPROC*

George_George21-Jun-06 17:22

George_George

21-Jun-06 17:22

Hi Zac,

Excellent!

regards,
George

Re: about FARPROC*

George_George24-Jun-06 2:12

George_George

24-Jun-06 2:12

Hi Zac,

I have found some new question about FARPROC. I found that in the definition in windef.h, FARPROC is dealing with a macro called far/near, for example, the following code segment,

<br />
#define far<br />
#define near<br />
#if (!defined(_MAC)) && ((_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED))<br />
#define pascal __stdcall<br />
#else<br />
#define pascal<br />
#endif<br />

Do you know what means far and near?

regards,
George

Re: about FARPROC*

Zac Howland25-Jun-06 8:20

Zac Howland

25-Jun-06 8:20

In Win32, FAR and NEAR are defined as nothing. In Win16, they were used to define the type of pointer (that is, where the pointer was in memory).

In other words, the following declarations are the same in Win32:

int FAR * myInt;<br />
int NEAR * myInt;<br />
int* myInt;

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: about FARPROC*

George_George27-Jun-06 2:22

George_George

27-Jun-06 2:22

Thank you Zac,

What do you mean "where the pointer was in memory"?

regards,
George

Re: about FARPROC*

Zac Howland27-Jun-06 3:17

Zac Howland

27-Jun-06 3:17

Back in the Win16 days, the hardware was 32-bits, but the OS was written for 16-bits. Thus, the actual area of memory you could address with a typical pointer was addressed in 16-bit address space. The OS simulated 32-bit pointers by using NEAR and FAR to specify whether it was in the lower or upper realm of memory. (In a nutshell). Neither of them have any meaning in portable code nor in Win32.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Re: about FARPROC*

George_George27-Jun-06 3:44

George_George

27-Jun-06 3:44

Cool, Zac!

You have answered my question.

regards,
George

A question about ClipCursor

zouchao111221-Jun-06 3:02

zouchao1112

21-Jun-06 3:02

Hi all
Now I want to lock the mouse in a dialog box. ClipCursor(&rect) is used in CMyDialog::InitialDialog(), and the mouse is locked in the dialog. However, if I move the dialog with dragging the title bar, the mouse is not locked this time. So I think WM_MOVE should be responsed, and ClipCursor is used again in CMyDialog::OnMove(), however, mouse is locked after moving in debug mode, but when I run the program free, the mouse is free as before, why is this? Should I set capture in the dialog?
CMyDialog::InitialDialog()
{
......
GetWindowRect(&rect);
ClipCursor(&rect);
}

CMyDialog::OnMove()
{
......
GetWindowRect(&rect);
ClipCursor(&rect);
}

Re: A question about ClipCursor

David Crow21-Jun-06 3:27

David Crow

21-Jun-06 3:27

zouchao1112 wrote:
Now I want to lock the mouse in a dialog box.

Why not use SetCapture()?

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

Re: A question about ClipCursor

zouchao111221-Jun-06 3:51

zouchao1112

21-Jun-06 3:51

SetCapture( )：
Causes all subsequent mouse input to be sent to the current CWnd object regardless of the position of the cursor.
From MSDN
It only captures the input of mouse, but do not confine the mouse move

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