Xojo

DataView updated to v1.16

by

This release includes a significant rewrite of internal rendering with major improvements for Retina displays!

Download it here.

In this release:

  • [New] Internal rendering overhaul.
  • [New] FPS greatly improved for HIDPI/Retina
  • [New] using dashed gridlines no longer slows rendering speed
  • [New] Added CellTextWidth method to get the required width to display the full text for a given cell
  • [New] Added ListColumn.AutoExpandWidth() to allow for automatically expanding column width to show all text in cells of that column
  • [New] Added property DefaultMaxColumnWidth to allow setting a default max width for new columns
  • [New] Added EndEditing parameter to cellDidEdit to allow preventing editing of next cell when tabbing out of editing cell
  • [Change] DataSource renamed to dvDataSource to avoid naming conflicts
  • [All] Fix for popupmenu cells not displaying the currently assigned value
  • [All] Fix for potential exception when user resizing columns
  • [All] Fix for situations where a dataview is embedded in a panel inside a desktopContainer
  • [All] Some improvements to scrolling when a drag is near the edge of the control
  • [All] Home and End keys now scroll to top and bottom of view
  • [All] Fixed a possible exception when resizing columns
  • [Mac] Fix for column alignment Center/Right on M1 Macs

Debugging the Undebuggable

by

Debugging the Undebuggable.

Beyond the Xojo IDE

by Jim McKay – piDog.com

Xojo has an excellent debugger that allows you to inspect values at runtime, step through code and get nice messages when something goes wrong. But sometimes this is not enough.

Have you ever found yourself pulling hair over some odd behavior? Maybe a messageBox isn’t showing up or you’re getting a “Segmentation Fault” in your Linux app.

Looking at the debugger is great, but there is more you can do.

Terminal is my co-pilot:

MacOS and Linux both come with Terminal applications that have almost identical functionality. The important part today is the ability to drop an app on a Terminal window , run the App and see messages that would normally be difficult, if not impossible, to locate.

On MacOS, an app is a bundle (a fancy folder), so this requires one extra step. Open Terminal.app, drop your app on the window, delete the extra space apple added after .app, and type /Contents/MacOS/[My\ Application] (Replace [My \ Application] with the name of your app). You can type the first character or two and press Tab to autocomplete the path names to save time. Hit Return and see if anything prints to the Terminal while you run through the steps to reproduce the behavior you’re trying to fix.

It’s not my segmentaion fault:

On Linux, you may find a situation where you run into a “Segmentation Fault”. This just means that code is accessing memory that either hasn’t been allocated, or has already been released. If the App is killed before Xojo can catch it, you’re out of luck. Running from the command line just gives you a “Segmentation Fault” message and ends the execution. Not much help either. Fortunately, Linux also has a nice built-in debugger called gdb.

To run gdb, open a terminal and type gdb followed by a space and drag your executable to the window. Press Return. If gdb isn’t installed, you’ll need to run “sudo apt-get install gdb” first (on Debian based distros). 

If you’re running from the Xojo IDE, be sure to uncheck “Launch executable after recieving” or use the “Project->Run Paused” menu if running locally.

Once gdb is running, you will type “run”. Run through the steps to cause the crash. gdb should stop execution and let you know that a “Segmentation Fault” has occurred. Now you can get a backtrace. Type “backtrace” or just “bt” and take a look. You’ll see a nice backtrace showing the stack to the current call that crashed your app.

If you need to pause execution at some point, just press control-C. If you need to kill the paused program, type “kill”. Type “quit” to exit gdb. If you want to see a more meaningful backtrace including function names, be sure to build for 64bit. 

A Window to your code:

Windows apps don’t have as simple a solution, but there is hope. Microsoft provides debugging tools that should be very helpful. WinDbg can help you dig in deeper than you’d probably like to go.

WinDbg is installed as a part of the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk

There’s too much to cover here, but Microsoft provides a nice getting started document: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/getting-started-with-windbg

(Jim is the owner of piDog Software and will be a presenter @ XDC 2019 in Miami Florida)