On macOS you may have noticed two special menu items that appear at the bottom of the Edit menu: “Start Dictation” and “Emoji & Symbols”. These menu items are added automatically by macOS provided your Xojo app follows a few simple rules.
When you start using Xojo one of the first things you’ll see is that there are many, many types of built-in controls. The area where you see all the controls is called the Library and each project type (desktop, web or iOS) has its own set of controls.
No matter the what type of project you are creating, learn these tips to make using the Library and finding controls fast and easy.
Although Xojo does not have a built-in method to format XML text, you can use XSLT to do this for you. XSLT stands for eXtensible Stylesheet Language. This XSLT can be used to format XML:
<?xml version="1.0" encoding="UTF-8"?> <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" indent="yes" /> <xsl:template match="/"> <xsl:copy-of select="/" /> </xsl:template> </xsl:transform>
To use this with Xojo, add a module to your project (name it XMLExtensions), add a String constant to the module (call it kXSLTFormat) and copy the above XSLT into the constant.
After seeing this conversation on the forums, I thought it would be helpful to run through why you can move some of your app’s DLLs but you cannot move others.
On Windows, the Visual Studio C Runtime DLLs can be in one of two locations on systems that do not already have them installed. All versions of Windows prior to Windows 10 would need these installed.
In many of our development projects, if not all, we are confronted with situations when we need to test our classes before the final deployment of a project. I’m not talking about Unit Testing here, though I highly recommend the excellent session on that topic from XDC 2018.
For example, it would not be desirable to send hundreds of emails to all the entries in a database simply to test one of the workflow steps or to verify that emails are being delivered as expected. It would be a lot simpler, and less disruptive to those using your app, to test using a few email addresses that are under your control.
So let’s establish a mechanism that allows us tell our apps when to run in a “simulated” mode vs. a “real” mode for all or some of the components that we need to test along the development cycle.
These days everyone has a great idea for an app. Maybe you have an idea that would save you time at work, or maybe you’ve been thinking of an app that would automate something you do at home. Not sure where to start? One of your first steps is choosing a development tool that is right for you and for your project.
Here are five questions to guide your decision:
If you spend enough time trying to predict the future, you learn that the more variables there are, the more difficult it becomes to determine a future. Take the weather for example. It’s not hard to predict tomorrow’s weather because there’s not much that will change over the next 12 hours or so. Try to predict the weather 7 days from now, 7 months or worse, 7 years from now, and your results will begin to vary dramatically.
This is certainly the case when it comes to writing apps. The bigger any one particular feature is, the more variables there are that affect it and thus the more difficult it becomes to predict how long it will take to finish. You don’t have to work in the software business very long to figure this out. Like most people in the software industry, we’ve been trying (with varying degrees of accuracy) to do this not just for our own internal planning but because we know you want, and need, to know as well.
While working on an app I found myself in an unexpected situation when a piece of code that had been working fine began to throw an
OutOfBoundException. After a bit of debugging I found that the culprit was the length of an array passed to the
AddRow method of a ListBox instance.