I wrote a basic CAPL program and included it as programming node in a CANoe measurement configuration.
The node will check the content of a specific message and create a Global Marker via createGlobalMarker() if the conditions are met. A write() statement ensures that the code portion is being executed. The CANoe configuration is being used in offline mode (I don't have a licence on this machine, no vector nodes are attached, I just want to replay stuff and check it out).
In the graphics window, no marker is created. No warnings are present in the write window. Here is the code mockup:
on linframe myFrame
{
output(this)
if( /* some condition */ )
{
write("code being executed");
createGlobalMarker("A","test"); // in actual code, the name is dynamic to avoid forbidden name duplicates
}
}
From the docs,
Sets a marker in CANoe Trace Window, Graphics Window and State
Tracker. The set marker can be displayed with the shortcut menu Show
in the marker bar of these windows.
So I would naturally expect to see the markers. I can create one manually from the Graphics window, and that one is displayed. I can't find the shortcut menu being referred to.
The marker bar is visible in the Graphics window and I can create a new marker by double-clicking on it.
The markers are added whenever the function createGlobalMarker() is triggered.
To view the markers in the Trace Window, it has to be in chronological mode.
Now, to view the marker created by your code, you have to right-click on the marker area (grey bar) to bring up the shortcut menu and select "Show > A" or "Show All". This will show the markers which your code has generated (with a lock symbol in graphics window).
Related
I'm running C++Builder 11.2, modifying an old program with a Form that contains a TImage and a TBitBtn (I first wrote the program 10 years ago, so I don't remember all of its details). A routine copies the Picture in the TImage to the Clipboard when the button is clicked.
The problem: The copy routine is also called when the mouse pointer is over the TImage and the C key is pressed. But I can't find the code where the mouse status and pressing the C key cause the copy routine to be called.
Can the debugger tell me what code is calling the copy routine?
Could the mouse-over-TImage condition and C key press be established outside of the normal code, such as somewhere in the Object Inspector?
This is the entire call stack for the problematic case:
I assume the numbers are addresses. How do I associate those with lines of code in my program?
This is a subtle problem that I inadvertently stepped into. The button that is used to capture the image has caption "Copy Image". I wanted to add code that would allow the image to be copied by pressing a keyboard key.
So, in anticipation of that, I began by adding one line of code to the MouseEnter event when the mouse pointer is over the image. That changed the caption so that the "C" in Copy is underlined. (A single line in the MouseLeave event changes the caption back.)
I used an ampersand (&) to add the underline. This is exactly how shortcuts are added to menu items. So, without thinking about it, I had added the shortcut that allowed the 'c' key to invoke the Copy Image button.
I'v create an Edit control dynamic by calling the constructor function and the Create function of CEdit:
m_pMyEdit = new CEdit;
m_pMyEdit->Create(style,zindex,100,100,100,100,pParentWindow,ID);
As you know, we can pass the this to the parent window parameter or set this parameter to another window. In my code, I passed the parent window parameter the value of:
CWnd::FromHandle(GetDesktopWindow())
This piece of code can get a pointer of CWnd (CWnd*) from the specific handle. Now run program and the Edit window shows at the position as we expect, and the caret shows in the Edit control and the focus is activited. But when I moved this edit to somewhere else, for example, move it to:
RECT rect = {200,200,100,100};
the caret disappear and the focus has been killed, further more, when I move the cursor on it, click mouse, the caret not appear and the focus not set any more. I have read the MSDN again and again, but I don't know why this happens.
By the way, the m_pMyEdit is the var of CEdit, I haven't derived the CEdit class yet.
I'm new to the Xcode User Interface testing framework. I can successfully manipulate the screen elements, but cannot work out how to produce a meaningful assertion about what text is visible in a scrolling view.
The test I would like to write would go as follows: launch the app, type lots of text into a text view (enough that the first line scrolls out of view), assert that the first line of text is not visible, scroll the view back up to the top, then assert that the first line is now visible. Note that the purpose of this test is to ensure my app has wired things up correctly, not to test Apple's code.
XCUIApplication allows me to type into my NSTextView instance, and also allows me to scroll the associated NSScrollView. But how do I assert whether the first line of text is currently visible? The value attribute on XCUIElement provides the entire text content of the view, whether or not it is currently displayed.
The accessibilityRange(forLine:) and accessibilityString(for:) methods on NSTextView would be ideal, but I can't see how to access them as the UI test only has access to an XCUIElement, not the underlying NSTextView.
Have I missed something, or is there a better way to approach this?
If you set the accessibility identifier in the storyboard or in code for the text view you can get the text view via (assuming you gave it the id "textview1" and the window it's in has the default accessibility identifier of "Window"):
let textview1TextView = app.windows["Window"].textViews["textview1"]
but that won't actually get you what you need.
Instead, set the accessibility identifier of the scrollview and get that:
let scrollview = app.windows["Window"].scrollViews["scrollview1"]
Then use that to get the scrollbars (you should only have one in this case; you can use scrollbars.count to check.
let scrollbars = scrollview.scrollBars
print("scrollbars count: \(scrollbars.count)")
Then you can use the value attribute of the scrollbar to get it's value:
(you're converting a XCUIElemenTypeQueryProvider into an XCUIElement so you can get it's value):
let val = scrollbars.element.value
it will be 0 at the top and a floating point value when scrolled (one line of text in my test code showed a value of {{0.02409638554216868}}.
Documentation that will help you explore further:
XCUIElementTypeQueryProvider
XCUIElementAttributes
Note that you can put a breakpoint in the middle of your test, run it and then use the debugger console to examine things:
(lldb) po scrollbars.element.value
t = 749.66s Find the ScrollBar ▿ Optional<Any>
- some : 0
(lldb) po scrollbars.element.value
t = 758.17s Find the ScrollBar ▿ Optional<Any>
- some : 0.05421686746987952
and while in the debugger you can even interact with your app's window to scroll it manually (which is what I did between typing in those two po calls), or perhaps add text and so on.
OK OP now noted that they're interested in the specific text showing or not rather than the first line in view or not (which is what I previously answered above).
Here's a bit of a hack, but I think it'll work:
Use XCUICoordinate's click(forDuration:, thenDragTo:) method to select the first line of text (use the view frame to calculate coordinates) and then use the typeKey( modifierFlags:) to invoke the edit menu "copy" command. Then use NSPasteboard methods to get the pasteboard contents and check the text.
Here's a quick test I did to validate the approach (selecting the first line of text using XCUICoordinate as noted above is left as an exercise for the reader):
NSPasteboard.general.clearContents()
// stopped at break point on next line and I manually selected the text of the first line of text in my test app and then hit continue in the debugger
textview1TextView.typeKey("c", modifierFlags:.command)
print( NSPasteboard.general.pasteboardItems?.first?.string(forType: NSPasteboard.PasteboardType.string) ?? "none" );
-> "the text of the first line" was printed to the console.
Note that you can scroll the selection off screen so you have to not scroll after doing the select or you won't be getting the answer you want.
I my application, I have added a dropdown box to the standard windows file open dialog. This works fine, but I would like to position this drop box exactly below the file name and file mask edit controls, and its label exactly below the labels for these controls.
How can I get the positions of these controls and the corresponding labels (it depends on the Windows version and maybe even on theming, so using the constants that make the dialog look fine on my computer won't do)?
On Vista+, you should be using the IFileDialog, IFileOpenDialog and IFileDialogCustomize interfaces:
Common Item Dialog
Customizing the Dialog
You can use the IFileDialogCustomize::AddText() and IFileDialogCustomize::AddComboBox() methods to add a drop-down list and its label to the dialog, and if needed use the IFileDialogControlEvents::OnItemSelected event to react to the user selecting items in your drop-down list.
However, you cannot decide where custom controls are displayed when customizing this dialog. UI layout is controlled by the dialog itself:
The Common Item Dialog implementation found in Windows Vista provides several advantages over the implementation provided in earlier versions:
...
•Enables simple customization of the dialog, such as setting the label on the OK button, without requiring a hook procedure.
•Supports more extensive customization of the dialog by the addition of a set of data-driven controls that operate without a Win32 dialog template. This customization scheme frees the calling process from UI layout. Since any changes to the dialog design continue to use this data model, the dialog implementation is not tied to the specific current version of the dialog.
...
The only layout access it provides is the order in which you add your custom controls, and any visual grouping. So, you could use IFileDialogCustomize::StartVisualGroup() to create a new group, then call AddText() and AddComboBox() (in that order) to add those controls to the group, and then finally call IFileDialogCustomize::EndVisualGroup().
On the other hand, when using GetOpenFileName() instead, there are some different options for customizing that dialog, and they allow you much finer grain control over the dialog's layout:
Customizing Common Dialog Boxes
Open and Save As Dialog Box Customization
The preferred option is to create a custom dialog box template and specify it in the OPENFILENAME structure. Within the template, you can have whatever controls and layout you want, and then the template can be inserted as a child of a standard Explorer-style dialog, or as a replacement for a standard Old-style dialog. MSDN documents how to custom-position a template within an Explorer-style dialog:
Explorer-Style Custom Templates
To make room for the new controls, the system expands the default dialog box by the width and height of the custom dialog box. By default, all controls from the custom dialog box are positioned below the controls in the default dialog box. However, you can override this default positioning by including a static text control in your custom dialog box template and assigning it the control identifier value of stc32. (This value is defined in the Dlgs.h header file.) In this case, the system uses the control as the point of reference for determining where to position the new controls. All new controls above and to the left of the stc32 control are positioned the same amount above and to the left of the controls in the default dialog box. New controls below and to the right of the stc32 control are positioned below and to the right of the default controls. In general, each new control is positioned so that it has the same position relative to the default controls as it had to the stc32 control. To make room for these new controls, the system adds space to the left, right, bottom, and top of the default dialog box as needed.
The alternative, without using a custom template, is to obtain the dialog's own HWND directly (which can be gotten inside a hook function assigned to the OPENFILENAME::lpfnHook field) and then you have full access to do whatever you want with the dialog. Microsoft assigned fixed control IDs to the standard controls of an Explorer-style dialog (so you must specify the OFN_EXPLORER flag for this approach to work), and those IDs are consistent across Windows versions. Those IDs are meant to be used with the CDM_SETCONTROLTEXT and CDM_HIDECONTROL messages, but they can also be used with GetDlgItem() to get the HWND of certain dialog controls, in this case the cmb13, edt1 and stc3 controls:
cmb13
Drop-down combo box that displays the name of the current file, allows the user to type the name of a file to open, and select a file that has been opened or saved recently. This is for earlier Explorer-compatible applications without hook or dialog template. Compare with edt1.
edt1
Edit control that displays the name of the current file, or allows the user to type the name of the file to open. Compare with cmb13.
stc3
Label for the cmb13 combo box and the edt1 edit control
Once you have those HWNDs, you can manually query their current positions and sizes, add your custom drop-down list underneath them as needed, and resize the dialog's HWND to accommodate your drop-down list.
Whether you use a template or direct HWND manipulation, you would need to use a dialog hook function to process messages from your drop-down list as needed, such as the CBN_SELCHANGE notification.
Is it possible to create a dialog using XUL (specifically in Firefox) that is:
Always-on-top but does not blocking user interaction with a page
and/or
Only tab modal, not window modal
?
You can surely have a non blocking Dialog, but it will go to the background when you click the window. For reference see this:
window.openDialog("chrome://membees/content/dialog.xul",
"","centerscreen=yes, all=no, titlebar=yes, chrome=yes, toolbar=yes,
dialog=no, resizable=no,modal=no","");
But if you want a bit more of control you can create a panel instead, and take advantage of the level property:
level
Specifies whether the panel appears on top of all windows, or just on
top of the window the panel is in. If this attribute is not set, the
popup window level depends on the platform. On Linux, the default
value is top, otherwise, the default value is parent. If a panel has
one or more text fields, this attribute should not be set, otherwise
IME or on-screen keyboard popups will appear incorrectly. For these
reasons, you should avoid setting the level if not needed.
top
The panel is shown in front of all other normal windows, including those of other applications.
parent
The panel is shown just above the window the panel is in, but behind
other windows above it. If anchored, the child window maintains its
relative position to its parent window.
floating
The panel floats above the window the panel is in. On Mac, the panel
is only visible when the application is active.
To create it you have to add it to the base element <popupset> in your overlay, and then you open it with:
openPopup(anchor,position,x,y,isContextMenu,attributesOverride,triggerEvent )