There used to be a checkbox for causality tracking in Extended Events. I don't see it anymore (SSMS 18.8) nor see anything about when where it would have been removed. Anyone know anything?
I had this same problem. The checkbox is still there, but below the bottom of the dialog window. Increase the size of the dialog window until it's visible. Perhaps there should have be a scrollbar.
Related
Recently, I've got stuck over strange UI issue, found a solution, but still unsure about problem cause.
Preconditions:
MFC MDI application has 2 modeless dialogs opened, both has a child third-party grid and CToolTipCtrl. Dialog windows crosses each other borders (i.e. active dialog is overlapping part of inactive one). CToolTipCtrl is similar to example, the only tool set for tooltip is grid. Parent of tooltip is There is the corresponding dialog's grid, TTS_ALWAYSTIP style is set to allow tooltips on inactive dialog.
Issue:
When mouse is hovering on inactive dialog's grid, tooltip is appearing and inactive dialog is drawn over active one. In other words, inactive window is brought to top without activating. It's drawn completely, including caption, buttons, grid, etc.
I've checked Z-order and found that inactive dialog is still inactive, even when shown on top. No Z-order changed. Then I gathered message log using Spy++ for whole inactive dialog while tooltip is appearing and found no WM_ACTIVATE, WM_FOCUS, WM_MDIACTIVATE, etc. Then I performed search about how to bring window up without activating and logged SetWindowPos calls - the only calls are performed for CToolTipCtrl's window. So, no SetWindowPos for dialogs called. No BringToTop() called as well.
Solution
I've changed tooltip's parent window from dialog's grid to dialog itself - and that fixed problem. However, I still have no idea what was happened and why changing parent attribute matters.
Question
Could anyone give me a hint about what I'm missing? Maybe, tooltip causes repaint of grid, and that repaint has a bug causing repaint over active window, but I haven't found any proofs yet.
Haven't found something specific about tooltip's parent property in MSDN as well. Maybe, I have to read somenting about Windows GDI?
I've a QTreeWidget and need to disable the mouse over highlighting on the childItems but not the click selection. The point here is, that I need to set this per Item because some are selectable. I was thinking about the QTreeWidget::itemEntered signal to check if the item should be highlighted or not but I can't get it to work because the description says
QTreeWidget mouse tracking needs to be enabled for this feature to
work.
and I can't figure out how.
So my questions for are: How can I enable mouse tracking?
Is there an easier way to disable the highlighting?
Simply invoke setMouseTracking() to enable mouse tracking for a specific widget.
I ran into this problem (I know this is an old post, but I might as well post my solution, since it can be useful for others).
I could not properly disable the mouse feedback while keeping the mouse tracking enabled, but I could make this feedback invisible. I'm using qss stylesheets, and I set the mousehover feedback color to transparent:
MyTreeWidget::item:hover {
background-color: transparent
}
It did the trick for me. Sadly it makes the feedback invisible all the time, rather than allowing to turn it off and on.
So as a next step, for when I needed it, I implemented my own feedback by using a delegate and overwritting the paint function.
The QTreeView overwrite mouseMoveEvent and sends mouse coordinates to the delegate. This way, the delegate can adapt what it does in paint to this position. It feels pretty heavy, and a bit dirty, but it works. Delegate should also allow to have different behavior for different items.
PS: If you're using a delegate, in most cases, that should be enough without the qss change. In my case it wasn't, because I call QStyledItemDelegate::paint in my overwritten paint method, so I inherited some unwanted behavior.
I have a CScrollview window.I have added copy-to-Clipboard functionality with doubleclick. But user does not know if it is happening or not. So I want to add a message box but that automatically vanishes or blends, so that user doesn't have to click OK button or anything. But I don,t want to make the popup or the vanishing of it too abrupt. I have no idea how to do it. Can I draw a BMP/PNG image and increase its transparency or something like that?
Anyone please guide me to the way to achieve it.
Note: my application is for xp/win7.
From VS2008 SP1 upward take a look at the CMFCDesktopAlertWnd class (MSDN here)
Quoting from the Remarks section on MSDN (my emphasis)
A desktop alert window can be transparent, it can appear with animation effects, and it can disappear (after a specified delay or when the user dismisses it by clicking the close button).
I am working on a project that totally does not want to use the built-in window/dock state and position saving of MFC. This means that in my main frame, I set EnableLoadDockState(FALSE). As much as I love to change it back to TRUE, I can't.
I plan on getting the position where a CDockablePane was docked through onAfterDock() of my CDockablePane. My problem is I have no idea on how to get whether it was placed on the side, top or bottom, on another CDockablePane.
Is there a way to get this information?
Thanks!
I think there is a way to get it, but it's not going to be easy or pretty.
A you're trapping the OnAfterDock, I guess you're not interested in floating panes. So, for docked panes, you can use CDockablePane::GetDefaultPaneDivider (MSDN here), which returns - as MSDN says:
A valid CPaneDivider object if the dockable pane is docked to the main frame window, or NULL if the dockable pane is not docked or if it is floating.
The CPaneDivider object (MSDN here)
...divides two panes, divides two groups of panes, or separates a group of panes from the client area of the main frame window
The following partial screenshot says more:
So, for a regular pane divider, you can use the methods available on CPaneDivider to find the other pane, or another embedded CPaneDivider (so recursive interrogation necessary here) and check if the divider is horizontal or vertical etc.
For the other case described above, look at the CPaneContainerManager class, which (again as MSDN says)
...manages the storage and display of the current docking layout
From here, you can again drill down through the whole docking hierarchy that starts from your original docked pane.
If I were you, I would really really look again at using EnableLoadDockState or at least browse the MFC source code to see if there are any internal helper classes/functions that you can reuse.
I've just solved this issue. I can check CDockablePane's dwStyle (GetPaneStyle()) for CBRS_ALIGN_LEFT, CBRS_ALIGN_RIGHT, etc. No complex methods. Simple.
I have a CFrameWndEx with several docked CDockablePanes but I can't seem to get notified when the size of the docked pane is changed (so I can resize my other windows accordingly). Tried Spy++ to check for messages, but custom draw seems to be the only one (which doesn't seem appropriate) and also tried overriding RecalcLayout, but that is not called under this circumstance. OnSize doesn't work because the size of the frame itself is not changed. Any ideas?
(Ps: I'm pretty sure it's possible because I used to have a splitter window as the 'client' area, and it would resize itself magically when the panes were resized)
OK this is a bit weird, but I had the exact same question, searched on Google, then saw that I had answered this question over a year ago but completely misunderstood what the question was about :)
Anyway for reference of future Google using people, the answer to this question is to override virtual void CFrameWndEx::EAdjustDockingLayout(HDWP hdwp) and do any resizing of client controls there. To get the client area after the hiding/closing/whatever of panes, use m_dockManager.GetClientAreaBounds(). My AdjustDockingLayout looks like this (m_View is the child window that is supposed to fill the whole client area regardless of the state of any docking panes, adjust as needed):
void CMainFrame::AdjustDockingLayout(HDWP hdwp)
{
CFrameWndEx::AdjustDockingLayout(hdwp);
if (m_View.GetSafeHwnd()) {
CRect rectUsable = m_dockManager.GetClientAreaBounds();
m_View.MoveWindow(rectUsable);
}
}
I think the issue is that the 'content' of the CFrameWndEx is itself a window, and in that window live the 'main content' windows. Check with Spy++ for the window hierarchy and if any of the child windows of the CFrameWndEx (other than the dockable panes) do get message when they are resized. Basically when docking panes are docked, the CFrameWndEx resizes its children, so you'd have to detect it there and (if required) reflect the message back to the CFrameWndEx if that's really where you need it.
Alternatively, maybe I'm misunderstanding and is what I described exactly what you're trying to do. In that case, I think there is something wrong with the way you add your window to the CFrameWndEx since that should handle the resizing itself. Is the parent of the child window set correctly to the CFrameWndEx when you create it?