I'm creating modeless child dialogs from a parent dialog class and i want to share the class data of its parent window with all child dialog classes I'll be creating. how would i go do that?
One way of doing it is to use SetWindowLongPtr():
SetWindowLongPtr(hwndParent, GWLP_USERDATA, (LONG_PTR)&parent_class);
This will set the USERDATA field on the parent hwnd to be the address of the parent class. Then in your WM_INITDIALOG handler, call GetWindowLongPtr() on your parent HWND and cast it back to the correct pointer type.
A better way to do it is to use CreateDialogParam() and in your WM_INITDIALOG handler you'll get the value you pass in the dwInitParam field, which would be the pointer to your parent class.
Related
I'm working on an MFC project (old technology, I know).
In my dialog-box class (derived from CDialog) I have:
CToolTipCtrl m_cToolTipCtrl;
CWnd m_cImageWindow;
In the class OnInitDialog function I do:
m_cToolTipCtrl.Create(this);
m_cImageWindow.CreateEx(...);
m_cToolTipCtrl.AddTool(this,_T("Parent"));
m_cToolTipCtrl.AddTool(&m_cImageWindow,_T("Child"));
In the class PreTranslateMessage function I do:
m_cToolTipCtrl.RelayEvent(pMsg);
When I run the project, the "Parent" tooltip is displayed whenever I hover within the parent window, but the "Child" tooltip is not displayed whenever I hover within the child window.
I have originally tried this without the "Parent" tooltip and it didn't work, so it is obviously not a matter of the "Parent" tooltip masking the "Child" tooltip.
I think that events are relayed only to the parent window, but I'm not really sure how to tackle this problem.
Putting a breakpoint in the PreTranslateMessage function is useless, since it stops eminently on every event that the application receives. How can I investigate this problem?
Found the answer:
Simply add the SS_NOTIFY flag to the child window style when creating it.
For example:
m_cImageWindow.CreateEx(0,WC_STATIC,NULL,WS_CHILD|SS_NOTIFY,{0,0,0,0},this,0);
What is the difference between WindowProc and CallWindowProc ?
I can imagine when registering a new window class I can specify my own WindowProc for it.
This leaves the question: When and what for do I use CallWindowProc ?
When you subclass a window using SetWindowLong/Ptr(GWL_WNDPROC) to assign a new WindowProc() to the window, the replacement WindowProc() uses CallWindowProc() when it needs to call the window's original WindowProc():
Subclassing a window
The preferred way to subclass a window is to use SetWindowSubClass() instead:
Safer subclassing
See msdn. CallWindowProc is used for subclassing.
I have a controller object that owns an NSMenu and is that menu's delegate, in the interest of lazy population.
However, neither numberOfItemsInMenu: nor menuNeedsUpdate: is ever called, and so the menu remains empty.
I have confirmed that:
The controller object has not been deallocated. (The controller, in turn, owns the menu.)
It does have a menu.
The menu does have a delegate, and that is the controller.
If I implement menuWillOpen:, that is called, but you're not supposed to populate the menu there.
I tried sending the menu an update message, and that had no effect. The delegate remained un-called, and the menu remained empty.
In case it's relevant: This menu is not in the main menu; it is used elsewhere.
Why isn't the menu asking its delegate to populate it? Is there something I've missed, or is this just broken?
Maybe you need a strong reference to the delegate.
Try moving variable declaration out of your method and make a class-level member variable.
look at this answer: https://stackoverflow.com/a/21816149/1664943
im new in cocoa ..
can any one say how yo pass values fromm one window to other
i tried but windowController
not allowing to create instance of other class
For passing one value to other Window ??
Window is just a view, you pass model's value, not view's values.
So, whenever you need to pass the value, you can use
Notification
Delegate
Shared Class.
In Cocoa, how do you define a class that sends an action? I want to be able to connect the action to the selector of another object in IB in the style of NSButton. I would prefer not to subclass NSControl if possible.
Give it a property (informal is fine) holding an id, for the target. I'm not sure whether this should retain or not; I'd say no, since the target will normally be the controller that owns the window that (indirectly) owns the view.
Give it a property (informal in fine) holding a SEL, for the action.
Respond to mouseUp: and keyDown: (checking that the key in question is the space bar or return or enter) by sending yourself an accessibilityPerformAction: message, passing NSAccessibilityPressAction.
Respond to the accessibilityPerformAction: message by either sending your action message to your target (NSAccessibilityPressAction) or calling up to super (other), as described in the documentation for that method.
You should also implement the rest of the NSAccessibility protocol while you're at it. Test that work with a mix of the Accessibility Inspector and VoiceOver.