NOTE: This should have no effect on the colors of these labels unless
you have changed the panel text color and control text colors to be
different. Both are black by default.
In the case of the menu field, spinner, check box, radio button,
slider, and text control labels we want to draw these labels using
the panel text color instead of the control text color because they
are drawn on top of the panel color. (the menu field label color was
changed in a previous commit in this push).
In all cases except the menu field the label color is specified by
temporarily unsetting the B_IS_CONTROL flag while drawing the label.
All use control look to draw the label.
The control text color is meant to be used for text INSIDE the control,
not the label text that accompanies the control -- at least that's the
way I understand it.
...instead of menu item text color when the label is unselected.
Menu item text color seems to make sense when the control is unselected
because we use selected menu item text color when the control is
selected, but, this isn't the case. We color the label background using
the menu item color because we are reproducing similar behavior of
BeOS R5. However, when the menu field is unselected the label needs to
draw so that it goes on the panel bg color.
There was a typo in the PROVIDES of the recipe that left the package
un-installable. Thanks vidrep for reporting and Diver for spotting
the issue! Closes#12694.
ImageListView:
- Add columns for the respective start and end addresses of the text and data
segments of each image. Correspondingly, adjust the table model to return
the appropriate fields from the image's info. This can come in handy for
quickly determining the approximate location of an otherwise unknown memory
address, among other things.
DwarfImageDebugInfo:
- When resolving the address of a PIC function that a value was
returned by, check if the resulting address actually belongs to
the same image as the caller. If not, find the appropriate image
for the new address. Combined with the previous commits, this fixes
the issue that functions called indirectly by PLT entry that jumped
to another image entirely wouldn't be mapped back to their
corresponding FunctionDebugInfo instance, and thus would be skipped
since we couldn't determine a type to associate the return value with.
ThreadHandler:
- When stepping over a function call, ensure that we actually have a valid
value for the stepped over function address before adding a return value
info entry. While this had no visible adverse effect, it did result in
unnecessary work when creating the list of variables to display later,
since such entries would have no valid function to resolve to, and thus
had to be ignored/thrown away.
DisassemblerX86{64}:
- Fix problematic usage of udis86 that was broken during an update.
Rather than calling the appropriate udis86 function to retrieve the
operand, we were accessing it directly on the ud struct, which was
fully filled in implicitly in previous versions of the library. However,
in the updated version of udis86, the operands are only lazily decoded on
request, and as such this data was invalid, leading to us not resolving
target addresses properly. This primarily affected determining the location
of return values.
ExpressionEvaluationWindow:
- Add team listener hooks for the various thread state changes.
- Implement these to react accordingly and keep the thread/frame menus
up to date with running program changes, whether due to user interaction
in the main team window, or background activities of the debugged app.
Previously the evaluation window needed to be closed and reopened to
refresh these appropriately.
* "ht" and "-ht" enable or disable the use of HT mode
(high throughput, 802.11n) for the wireless network device
* Analogous to the option with the same name in FreeBSD's ifconfig
* Disabling HT before associating with an AP is a workaround for
connection instability issues encountered with iprowifi4965
driver
...and rename fBitmap to fOffscreenBitmap to make it more clear what it is.
We don't need to save a pointer to both the offscreen bitmap and
the offscreen view, just the bitmap. We can access the view by calling
fOffscreenBitmap->ChildAt((int32)0). This gives us back a _reserved private
variable slot.
In the (unlikely) case that _InitData() is called with offscreen = false but
the fOffscreenBitmap is not NULL, delete fOffscreenBitmap before
setting it to NULL so that memory is not leaked.
App Server sends each window a message that the screen has changed:
https://www.haiku-os.org/legacy-docs/bebook/BWindow.html#BWindow_ScreenChanged
Propegate B_SCREEN_CHANGED message to all child views first
Tell BColorControl to read the B_SCREEN_CHANGED message and reinitialize itself.
* Only reinit if switching to or from B_CMAP8
* Initialize all pointers to NULL in constructor
* Don't destroy and rebuild offscreen view (and text views) on reinit
* Reinitialize offscreen view on reinit.
Fixes#8035
Also initialzing the pointers to NULL in constructor fixes#12673
...instead of doubleBuffered for the flag that specifies whether or not to
draw using an offscreen buffer.
Also remove the (not currently used) text from the docs since the parameter
is being used.
* Use print format macros to fix the 64 bit build.
* Correct a typo in the shift of the trigger mode definition. As the
value is 0 either way, this does not make a functional difference.
* Use macros instead of values in comparisons.
This allows usb_ecm to work in case it is part of a device using
different configurations for different types of interfaces and ECM is
not the first configuration.
While the USB descriptors are specifically built in such a way that it's
always possible to correctly query the max packet size, some devices
unfortunatley use bogus values in their descriptors and rely on the
stack to use the mandated values.
This fixes USB devices in VirtualBox when EHCI emulation is used. This
really is a bug in their descriptor emulation though.
Don't initialize the current qtd field with the terminate bit as it does
not exist in this field. While the lower 5 bits are documented as being
ignored anyway, this is more correct. Should cause no functional change.
