C / C++ / MFC Discussion Boards

ray_li25-Jul-03 3:40

25-Jul-03 3:40

Hi! everybody:

I'm developing a ActiveX control which is a windowless, If I find something special in my class, I want to SendMessage to this ctrl and let it do something , but I can not get the window handle of this ctrl, so this ctrl also can not get this message.(I have tried AfxGetMainWnd, it doesn't work)

Does anyone has similar experience? Plesae give me some ideas, I'll appreciate
your help.

Ray

Re: How to SendMessage to a windowless Ctrl

valikac25-Jul-03 5:28

valikac

25-Jul-03 5:28

One possible solution is to have the client pass the ActiveX server a handle of its window. Another solution is a callback interface.

Kuphryn

Re: How to SendMessage to a windowless Ctrl

ray_li25-Jul-03 7:08

ray_li

25-Jul-03 7:08

Thank you for your answer.

But I just wonder which function I can call to get the client handle, I have tried AfxGetMainWnd(tested it in Activex Ctrl test Container, it doesn't work).

Thanks again

Ray

Re: How to SendMessage to a windowless Ctrl

G. Steudtel25-Jul-03 5:47

G. Steudtel

25-Jul-03 5:47

Hi,
I always thought controls are windows, sometimes invisible.
You can only send messages to windows, even invisible ones (sinks).
One possible way is to use HWND_BROADCAST as window handle. Then every window will get that message. Works well with registered messages, because those are igmored by all but your windows.

The next way would be, to register a message like
MSG_GET_HANDLE ("Hey give me your Handle") and a Message MSG_MYHANDLES ("Here you got it").

So in your ActiveX control, you have a handler for GET_HANDLE and in your application you have a handler for MYHANDLES.

All you have to do, ask all windows to send you their handles. And because only your control understands this message the response will be the handle of your control window. So store the LPARAM as handle of your control handle.

If you really have no window, than you must use THREAD_MESSAGE. But then your ActiveX control must be derived by CCmdTarget I think. Didn't try this one.

Regard

G. Steudtel

Re: How to SendMessage to a windowless Ctrl

ray_li25-Jul-03 7:39

ray_li

25-Jul-03 7:39

Thank you so much for your answers.

You idea is very good, Could you tell me where I can find some articls about
this, so I can get more detailed reference to save time in this samall but tough thing.

Ray

Re: How to SendMessage to a windowless Ctrl

BadJerry25-Jul-03 6:31

BadJerry

25-Jul-03 6:31

I may have missed your point, but why not create a method that you would call when you have that "something special"?

Disable window close [X] button

David Chamberlain25-Jul-03 3:36

David Chamberlain

25-Jul-03 3:36

Okay, I know I have seen this before. But now, when I need it, I can't seem to find it. Any help will be most appreciated.

I have and MDI app with 2 child windows, one of which I would like the users not to be able to close, at least not easily. I would like to disable the [X] button so it won't accidently be hit, but I can't locate an easy way to do it.

I did Google and found a couple of question/answer pages, but the solutions didn't work. They dealt with changing the system menu. Isn't there a style element or something easy?

As I said, any help will be most appreciated.

Thanks,
Dave

"You can say that again." -- Dept. of Redundancy Dept.

Re: Disable window close [X] button

Member 42425925-Jul-03 3:55

Member 424259

25-Jul-03 3:55

do it by Calling SetWindowLong(GWL_STYLE)

Thanx
TAKE CARE

Re: Disable window close [X] button

David Chamberlain25-Jul-03 4:16

David Chamberlain

25-Jul-03 4:16

SetWindowLong? Thanks. What value should I use to disable the close button then?

Dave

"You can say that again." -- Dept. of Redundancy Dept.

Re: Disable window close [X] button

valikac25-Jul-03 5:30

valikac

25-Jul-03 5:30

One solution is EnableMenuItem().

GetSystemMenu(FALSE)->EnableMenuItem(SC_CLOSE, MF_DISABLED);

Kuphryn

Re: Disable window close [X] button

David Chamberlain25-Jul-03 7:01

David Chamberlain

25-Jul-03 7:01

The problem I have with this approach is that as a child window, there is no system menu for it, and I get an unhandled exception. This is when I put these statements in the OnCreate handler of the child window.

When I put this in for the main frame, then indeed it does disable the close, but for the main window, not for the child.

Thanks,
Dave

"You can say that again." -- Dept. of Redundancy Dept.

Re: Disable window close [X] button

John M. Drescher25-Jul-03 8:39

John M. Drescher

25-Jul-03 8:39

That should work anyways. See the doc for CWnd::GetSystemMenu.

CWnd::GetSystemMenu
CMenu* GetSystemMenu( BOOL bRevert ) const;

Return Value

Identifies a copy of the Control menu if bRevert is FALSE. If bRevert is TRUE, the return value is undefined.

The returned pointer may be temporary and should not be stored for later use.

Parameters

bRevert

Specifies the action to be taken. If bRevert is FALSE, GetSystemMenu returns a handle to a copy of the Control menu currently in use. This copy is initially identical to the Control menu but can be modified. If bRevert is TRUE, GetSystemMenu resets the Control menu back to the default state. The previous, possibly modified, Control menu, if any, is destroyed. The return value is undefined in this case.

Remarks

Allows the application to access the Control menu for copying and modification.

Any window that does not use GetSystemMenu to make its own copy of the Control menu receives the standard Control menu.

The pointer returned by the GetSystemMenu member function can be used with the CMenu::AppendMenu, CMenu::InsertMenu, or CMenu::ModifyMenu functions to change the Control menu.

The Control menu initially contains items identified with various ID values such as SC_CLOSE, SC_MOVE, and SC_SIZE. Items on the Control menu generate WM_SYSCOMMAND messages. All predefined Control-menu items have ID numbers greater than 0xF000. If an application adds items to the Control menu, it should use ID numbers less than F000.

Windows may automatically dim items on the standard Control menu. CWnd can carry out its own checking or dimming by responding to the WM_INITMENU messages, which are sent before any menu is displayed.

John

Re: Disable window close [X] button

Bob Stanneveld25-Jul-03 9:59

Bob Stanneveld

25-Jul-03 9:59

You should be able to create a system menu. In the PreCreate() function add the style for the system menu, then disable the clost button which was explained by the other users.

hope this helps (I'm not sure it will though Blush | :O

)

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Re: Disable window close [X] button

jason9925-Jul-03 5:51

jason99

25-Jul-03 5:51

take a look at my homepage under:

http://www.code-diary.com/HTML/Diary/0001.htm

greets,
Jason

Virtual function CDialog::OnCancel()

Anonymous25-Jul-03 3:20

Anonymous

25-Jul-03 3:20

Hi
I have a little, but pain-in-the-ass type of problem.

I virtually override the OnCancel() function:
'virtual void OnCancel()'

Then at the implementation
void CMyStupidDialogName::OnCancel()
{
::AfxMessageBox("ONCANCEL");
}

I've added the (X) button on the dialog. I press that standard (X) button in the right corner of the dialog and my code isn't executed (oncancel).

Isn't pressing that button equal to canceling?

Re: Virtual function CDialog::OnCancel()

Ryan Binns25-Jul-03 3:24

Ryan Binns

25-Jul-03 3:24

Anonymous wrote:
Isn't pressing that button equal to canceling?

No. It returns the IDCANCEL value from DoModal(), but OnCancel() is not called.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Re: Virtual function CDialog::OnCancel()

Bob Stanneveld25-Jul-03 3:34

Bob Stanneveld

25-Jul-03 3:34

It's isn't called the 'close' button for nothing Poke tongue | ;-P

maybe you should override the OnClose() function...

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Re: Virtual function CDialog::OnCancel()

Anonymous25-Jul-03 3:35

Anonymous

25-Jul-03 3:35

ah damned

your right (like always Poke tongue | ;-P

)

uhm .. it's getting time for weekend i would say Wink | ;)

Thanks for the help Smile | :)

Re: Virtual function CDialog::OnCancel()

Anonymous25-Jul-03 3:54

Anonymous

25-Jul-03 3:54

well i will have to disappoint you all guys

i've overwriten the onclose() one like this:
void CMyStupidDialogName::OnClose()
{
app->bClosed = true;
CDialog::OnClose();
}

i debug (run to cursor) and you were right the onclose part is executed but the form is still not closed.

Re: Virtual function CDialog::OnCancel()

Bob Stanneveld25-Jul-03 9:49

Bob Stanneveld

25-Jul-03 9:49

So you added a close button ON the dialog in addition to the standard close button?

If I'm correct, try the following:
the declaration in CMyStupidDialogName

afx_msg void OnYourButtonPressed();

the implementation

void CMyStupidDialogName::OnYourButtonPressed()
{
    PostQuitMessage(-1);
}

map that function to the button this way:

DECLARE_MESSAGE_MAP(CMyStupidDialogName, CDialog)
    // other message handlers,...
    ON_BN_CLICKED(YOUR_BUTTON_ID, CMyStupidDialogName::OnYourButtonPressed)
END_MESSAGE_MAP()

this should work Smile | :)

if it doesn't, slap me Poke tongue | ;-P

A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.

Re: Virtual function CDialog::OnCancel()

yitzhak25-Jul-03 11:19

yitzhak

25-Jul-03 11:19

Hello

Your problem is that you forgot to call the default handler for OnCancel().

void CMyStupidDialogName::OnCancel()<br />
{<br />
     ::AfxMessageBox("ONCANCEL");<br />
     CDialog::OnCancel();<br />
}

Isaac Inyang
Ansyl Technologies

Inline function insanity.

⁷³Zeppelin25-Jul-03 3:15

⁷³Zeppelin

25-Jul-03 3:15

Can someone explain what the vc++ compiler does in these two
particular instances:

Scenario #1:
I have an inline function, let's call it InlineFunction(). It will
return type int and accesses a private member variable of a particular
class. It is a public member function of the same class, MyClass...
Now consider the following lines of code:

void main()
{
MyClass ThisClass;

// do stuff.....

cout << ThisClass.InlineFunction() << endl;

return 0;
}

Scenario #2
Same as above, only we assign the value of
InlineFunction to a variable:

void main()
{
MyClass ThisClass;

int temp;

// do stuff

temp = ThisClass.InlineFunction();

cout << temp << endl;

return 0;
}

Can anyone tell me how the compiler handles the inline function
in the two different scenarios? I realize that it expands the function
in the code, buy how is scenario #2 different from #1 in terms of how the
compiler handles the situation??

Re: Inline function insanity.

Ryan Binns25-Jul-03 3:23

Ryan Binns

25-Jul-03 3:23

John Theal wrote:
how is scenario #2 different from #1 in terms of how the
compiler handles the situation??

No difference at all. The compiler simply replaces a function call with the actual code for the function. Where the function appears is irrelevant, unless it is a recursive call to an inline function.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Re: Inline function insanity.

Member 42425925-Jul-03 3:24

Member 424259

25-Jul-03 3:24

i dont think so that there is any change i mean in the 1st case the return value by the function is directly place from where it is called. i mean the cout<< "here is the returned value"
while that in the 2nd senario the retuen value is being assiged to the var and that particular var is used to display the value with the cout object.
i dont think so there is much difference in the 2 senrio.
if any one can tell more its good isnt it..

Thanx
TAKE CARE

Re: Inline function insanity.

David Crow25-Jul-03 5:29

David Crow

25-Jul-03 5:29

Have you looked at the assembly output of the two? That'll tell you what the compiler is doing to each.

Last Visit: 31-Dec-99 18:00 Last Update: 23-Jun-24 16:04

Refresh

ᐊ Prev 1...14554 14555 14556 145571455814559 14560 14561 14562 14563 Next ᐅ

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