{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "The ZAZ", "home_page_url": "https:\/\/thezaz.com\/", "feed_url": "https:\/\/thezaz.com\/blog\/json.php", "icon": "https:\/\/thezaz.com\/gfx\/giant_logo.png", "favicon": "https:\/\/thezaz.com\/gfx\/favicon120.png", "author": { "name": "Thom McGrath", "url": "https:\/\/twitter.com\/tekcor", "avatar": "https:\/\/secure.gravatar.com\/avatar\/0213452f7a795f1ccb2bfc27bbde2620?d=identicon&s=512" }, "items": [ { "id": "f0ff3aaa-171a-4163-8df6-c6dad6b3cfd2", "url": "https:\/\/thezaz.com\/blog\/quick_tip_setting_reminders_in", "title": "Quick Tip: Setting reminders in your Xojo code", "content_html": "
If you're in the middle of refactoring and find something that needs to be done, but you're not quite ready to tackle it yet, here's a nice way to make sure you don't forget.<\/p>\n
#If<\/span> DebugBuild\n #Pragma<\/span> Warning "This isn't implemented yet"<\/span>\n#Else<\/span>\n #Pragma<\/span> Error "This isn't implemented yet"<\/span>\n#EndIf<\/span><\/span><\/code><\/pre>\nYou can of course add comments or anything else you need to help you remember. And the message can be anything you like. The point is this will show the message in Xojo's analyzer (which you should<\/em> be using) but still allow you to run and debug the project. But if you try to build, you'll get stopped. This way you won't accidentally ship a build to your customers that has missing functionality.<\/p>",
"date_published": "2021-10-17T17:48:25+00:00",
"date_modified": "2021-10-17T17:48:22+00:00"
},
{
"id": "350d9459-c1be-4178-a883-2a1213f77f32",
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color",
"title": "Setting your own accent color for Xojo macOS apps",
"content_html": "As of Big Sur, applications can provide their own accent color for things like default buttons, focus rings, selection indicators, checkboxes, radio buttons, and so on. I personally really like this, as it allows Mac apps to have just a little more personality. Unfortunately, Xojo does not have a built-in option for this and most likely never will. This isn't because Xojo doesn't want<\/em> there to be, but because doing so requires reverse engineering Apple's compiled asset catalog format.<\/p>\nIn this guide, I'll teach you how to set this up by first creating an asset catalog in Xcode, compiling that catalog, and utilizing it in your macOS app. I'll cover everything you need to know, step by step, even if you've never used Xcode, the command line, or any of Xojo's automation tools. This guide assumes Xcode is already installed however.<\/p>\n
A brief introduction to asset catalogs<\/h3>\n
Developing apps for Apple devices these days typically includes something called an asset catalog. It can store color sets and image sets, similar to Xojo's ColorGroup and ImageSet classes. These catalogs can be manipulated by Apple during distribution. For example, downloading an iOS app on an iPhone Pro Max will automatically strip away the 1x and 2x resolutions of images that have a 3x resolution. By doing so, they allow Apple's app stores to deliver more optimized downloads.<\/p>\n
The good news is that asset catalogs are pretty simple. They are just folders full of images and json files. Xcode has an editor for them that you absolutely should use. The bad news is that the asset catalogs cannot be used as-is and require being compiled into a \"car\" file first. This is done with the actool<\/code> command line tool, which is included with Xcode. For Xojo to allow custom accent colors, they would need to replicate this process. This is why the feature will likely never come to Xojo.<\/p>\nCreating your asset catalog<\/h3>\n
Launch Xcode, and from the File menu choose \"New -> File\u2026\" or just press \u2318N. From the template chooser, find \"Asset Catalog\" under the \"Resource\" header. The filter field helps with this. You will immediately need to save this folder somewhere. I recommend keeping it near your project of course.<\/p>\n
Now you have an empty asset catalog. At the bottom of the left column, use the plus button to choose \"Color Set.\" A new row will be created ready for you to name it. I called mine ThisIsTheAccentColor<\/code>. In the larger content area, you will have two white squares for \"Any Appearance\" and \"Dark\" with no obvious way to set the colors. From the View menu, choose \"Inspectors -> Attributes\" or \u2325\u23184. In the newly-opened attributes inspector you'll see an Appearances menu on the right. The default of \"Any, Dark\" is what I recommend because nearly every color needs some sort of adjustment for dark mode, even branding colors. In this context, \"Any\" means anything that is not dark mode. That would include light mode, and any future modes that Apple may or may not introduce. You can choose \"Any, Light, Dark\" instead, to supply an explicit light mode code, but considering we don't know what other options might be added, there's little purpose in doing so.<\/p>\nClicking one of the squares adds the \"Color\" section to the attributes inspector, which will default to sRGB content. That's good. Use the options to set your color. Repeat as necessary for each square to complete the color set.<\/p>\n
<\/p>\n
At this point, you're done with the asset catalog itself, though there are some more neat things that can be done with it in the future. The asset catalog is how you would activate Big Sur's system-generated document icons, for example. But for now, we've done everything we need to.<\/p>\n
Creating an Info.plist file<\/h3>\n
Every app for every Apple device has an Info.plist<\/code> file inside of it. Xojo will generate it for you, but you need to add a new value to it that Xojo does not support. If you already know how to do this, you need to add NSAppAccentColorName<\/code> as a string set to the name of your color set. Mine will be set to ThisIsTheAccentColor<\/code>. Skip to the next section if you're comfortable doing this, or read on if you're not.<\/p>\nStill in Xcode, you need another new file. Again, choose \"New -> File\u2026\" from the File menu. This time in the template chooser, you need to select \"Property List\" from the \"Resource\" header. Like before, you need to save it immediately, however this time it must<\/strong> be named Info.plist<\/code>. Save it near your project like you did the asset catalog. In the first row below the header, you'll see \"Information Property List.\" Hover your cursor in that row along the right edge of the column until a plus button appears. Tap it once, and a menu of choices will appear. For some reason, the one we need is not in this menu. So instead, type NSAppAccentColorName<\/code>. In the \"Type\" column, make sure the type is \"String.\" If it isn't, clicking the type will open a menu allowing you to change it. Lastly, in the \"Value\" column enter the name of your color set from the asset catalog. Remember I named mine ThisIsTheAccentColor<\/code> so that's what I'll enter here. Save your Info.plist<\/code> and you can exit Xcode if you like.<\/p>\n<\/p>\n
Compiling your asset catalog<\/h3>\n
Next up, we'll need to compile the asset catalog. This is done using the command line. I'll walk you through it as best as I can assuming you have no experience with it. Launch Terminal and type actool --compile ~\/Desktop --platform macosx --minimum-deployment-target 10.11<\/code>, but do not<\/strong> press return. Make sure what was typed ends in a single space, because web browsers tend to trim it off the end. Next find your asset catalog and drag it into your Terminal window. This will add the full path to the end of the command and will look something like actool --compile ~\/Desktop --platform macosx --minimum-deployment-target 10.11 \/Users\/thommcgrath\/Desktop\/Accent\\ Color\\ Sample\/Media.xcassets<\/code>. Press return to begin the work, which will take a couple seconds. When it completes, you'll see some XML output. It will have put an Assets.car<\/code> folder on your desktop. Move this near your project, but do not rename it. You're done with Terminal.<\/p>\nFor those more experience with the command line, you can of course change the destination using the --compile<\/code> parameter.<\/p>\n<\/p>\n
Adding the files to your Xojo project<\/h3>\n
If you already know how to use build automation, you'll need to have your Assets.car<\/code> file added to your app's resources folder. If you don't know how to use build automation, follow the steps in the next paragraph.<\/p>\nIn your Xojo project, use the Insert menu to choose \"Build Step -> Copy Files.\" Name this object as descriptive as possible. Something like CopyResourcesMac<\/code> would be good, in case you need one for Windows and Linux in the future. In the inspector, set the Destination to \"Resources Folder\" and then drag your Assets.car<\/code> file into the middle list. Then drag this build step into the \"macOS\" checkbox below \"Build Settings\" in Xojo's navigator. The navigator will gain a \"Build\" item as a child of \"macOS\" and your build step will be listed just before it. You need to move your build step after that \"Build\" item. Most build steps should be triggered after the build itself, but some can be placed before it if the step were to change the project prior to building.<\/p>\nFinally, add your Info.plist<\/code> file to your project. Just drag it right into the navigator. Xojo will include its keys during the build process.<\/p>\n<\/p>\n
Test it out<\/h3>\n
That's it, you're done. Run your application and your buttons will have the new color. If they do not, check your System Preferences. Under General, make sure the accent color is set to \"Multicolor\" so that apps may pick their own. The colors should immediately change in your app.<\/p>\n
And here's some screenshots of the hideous colors I chose:<\/p>\n
\n<\/p>",
"date_published": "2021-09-25T18:52:33+00:00",
"date_modified": "2021-09-25T18:52:29+00:00",
"attachments": [
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/Accent+Color+Sample.zip",
"mime_type": "application\/zip",
"title": "Accent Color Sample.zip",
"size_in_bytes": "9818"
},
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/accents_asset_catalog.png",
"mime_type": "image\/png",
"title": "accents_asset_catalog.png",
"size_in_bytes": "528456"
},
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/accents_info_plist.png",
"mime_type": "image\/png",
"title": "accents_info_plist.png",
"size_in_bytes": "254648"
},
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/accents_terminal.png",
"mime_type": "image\/png",
"title": "accents_terminal.png",
"size_in_bytes": "438446"
},
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/accents_xojo_project.png",
"mime_type": "image\/png",
"title": "accents_xojo_project.png",
"size_in_bytes": "696751"
},
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/accents_light_mode.png",
"mime_type": "image\/png",
"title": "accents_light_mode.png",
"size_in_bytes": "255297"
},
{
"url": "https:\/\/thezaz.com\/blog\/setting_your_own_accent_color\/accents_dark_mode.png",
"mime_type": "image\/png",
"title": "accents_dark_mode.png",
"size_in_bytes": "269161"
}
]
},
{
"id": "f7e2eda5-2b1e-43c4-a8c0-9619f317806f",
"url": "https:\/\/thezaz.com\/blog\/its_time_to_turn_this_ship_aro",
"title": "It's Time to Turn This Ship Around",
"content_html": "
For a tool that has been with me for more than half my life, generates 100% of my income, and I've poured five years of my life into developing... I give Xojo a hard time. I realized over on the \"Xojo Blogs and Resources\" page of ifnotnil.com that my blog includes an \"often critical\" component to its description. It's not wrong, but that needs to change. When was the last time I wrote something trying to help developers do their jobs? I had a spat of tutorials a year ago, but before that my last tutorial was December 2013.<\/p>\n
I don't mind being critical of Xojo. I do mind when it's all I do on this site. That'll change.<\/p>",
"date_published": "2021-06-30T20:51:52+00:00",
"date_modified": "2021-06-30T20:51:49+00:00"
},
{
"id": "46175c48-5f53-4f48-a0e8-c864bd1946e2",
"url": "https:\/\/thezaz.com\/blog\/xojos_user_confidence_problem",
"title": "Xojo's User Confidence Problem",
"content_html": "
The recent Xojo is technical debt<\/a> discussion on the Xojo forum has sparked some thoughts in my mind. This isn't really about that discussion though, otherwise I'd keep all my thoughts there. But some of the comments about Xojo's quality has me wanting to write about my experiences both inside and outside the company. Many blame the rapid release model for Xojo's perpetual beta status, but I don't think it's that simple. In fact, I think the rapid release model is a symptom, not the cause.<\/p>\nIn most projects there exists at least two branches of development. Though their names may vary, at the high level they are the stable and dev branches. Bug fixes are typically made to stable and merged into dev, while features are made into dev and merged into stable only when it's time for a new feature version. Stable versions can be released with great frequency, giving more time for the next feature version to become ready for release. In very well organized projects, every feature is given its own branch and merged into a feature release only when appropriate.<\/p>\n
Xojo doesn't really operate this way. There are still two branches of development, but they only overlap during the testing period. Once a release is declared finished, all work - both bug fixes and features - are made to the same branch. This is because Xojo doesn't want<\/em> to make point releases. They do it only in exceptional cases.<\/p>\nAs I mentioned earlier, the rapid release model is a symptom. The cause is Xojo's desire to have their cake and eat it to. Their pricing model wants to be a subscription. Subscription software is very desirable for revenue because even if you don't make more money, you can make consistent money. With my own Beacon app, I could probably make at least twice as much money selling it as a subscription. I don't because I hate subscription software. And therein lies the problem: people dislike subscription software. So the rapid release model was introduced to get close to a subscription without actually being<\/em> a subscription. They want to sell you a year of updates and in order for you do not feel cheated by that, they promise a certain number of feature releases per year.<\/p>\nThat's not a bad thing in and of itself. Such a model could work, and one could argue it is working, as Xojo has been doing this for years now and they are still in business. But the fact that customers complain about this model is maybe an indication that something could be improved.<\/p>\n
The heart of the problem is that we get 3-4 feature releases per year, and very few bug fix releases. I'd like to see more bug releases. At one point the team talked about being able to deliver framework fixes weekly. That might be a bit extreme, but a new build of fixes every other week would be remarkable. Then every 3 months (or so) we'd get a feature release. Heck, I'd be happy with feature releases every 6 months.<\/p>\n
While working at Xojo counter arguments about quality with the fact that each release sees hundreds of bug fixes. That's true, but it also brings with it additional changes which make developers uneasy about updating their Xojo version for existing projects. As the saying goes, the devil you know is better than the devil you don't. Developers would rather work with the bugs they are aware of than risk discovering new bugs, which Xojo has a habit of introducing each release. And since releases don't happen for months, we have to suffer those bugs for a long time, if they even get fixed for the next release.<\/p>\n
That's why more frequent bug fix releases would do wonders for the community. If I update my IDE mid project and discover a bug, when a bug fix release is only a couple weeks away, I can probably wait it out. There's no guarantee the next bug fix release will include the fix, but it could. I'd still rather wait 4 or 6 weeks for a fix than the minimum of 12 we wait now.<\/p>\n
Every developer knows that feature releases have the most bugs. Mine do. It's very normal for the \".0\" releases of anything to be the most buggy. But most developers correct that pretty quickly with bug fix releases shortly after the feature release. Xojo does not, and that<\/em> is where the customer confidence problem comes from.<\/p>\nIf Xojo wants to shake this \"fix one thing, break two more\" reputation, they need to actually release rapidly. I sure as hell wouldn't be successful only making 4 releases per year, and my app is much simpler than Xojo.<\/p>",
"date_published": "2021-06-28T19:47:04+00:00",
"date_modified": "2021-06-28T19:45:37+00:00"
},
{
"id": "e7a1bb1a-cfac-45cc-8c43-5e34078df219",
"url": "https:\/\/thezaz.com\/blog\/a_story_of_homeownership_and_t",
"title": "A story of homeownership and things only exciting to adults",
"content_html": "
When we bought our second car, we managed to clean out the second bay of the garage to begin parking it inside with the other. But the garage door opener from 1979 just couldn\u2019t accept a remote. I couldn\u2019t find an option online, nor could an expert find any way to make it happen. In the winter, this was especially frustrating, as it meant my wife could not close the garage on her way out in the morning, letting all that nice cold air in.<\/p>\n
So I set out to have it replaced. After it took a friend and myself 12 hours to install my Ryobi opener about 4 years ago, this was a project I was confident I did not want to do myself. I also decided that I hated that Ryobi opener enough that I wanted it replaced too. I found an installer who estimated it would cost me about $300 to install both, so I ordered a couple Chamberlain openers and setup the appointment. I wanted the better Liftmaster models, but just couldn\u2019t justify the price. So this project was estimated at around $800 altogether.<\/p>\n
The day before the appointment, the guy who will be doing the work calls to find out what exactly I ordered so he can give me an accurate price. He tells me it would cost me $800 each<\/strong> to have them installed, because the Chamberlains come in a zillion pieces and they take much longer to install. I guess their dispatch assumed I was buying something from Liftmaster, which don\u2019t need to be packaged to fit onto store shelves. They come in larger pieces that are significantly faster to install. So my options were: cancel the appointment, install the Chamberlains for $2100 total project cost, or install Liftmasters for $1200 total project cost. Since I originally wanted the Liftmasters anyway, you can guess which option I chose.<\/p>\nThe guy comes out the next morning and starts to see what he\u2019s working with. And it\u2019s not good. All the equipment, aside from the Ryobi opener, is original from 1979 when the house was built. One of the tracks are bent, some of the rollers are busted, and even the springs are too weak. I think odds are they are too weak because they were<\/em> replaced at some point, but I have no record of that. So he can continue with the installation, but he\u2019d have to void the warranty and couldn\u2019t promise the openers would even move the doors. Newer models are much more sensitive for safety, and might detect the extra weight as an obstruction. He could refurbish the hardware, but that means replacing the tracks, taking the doors down, etc. which takes a lot of time. To refurbish the doors and install new openers, would be $3200 total project cost. This project has grown in price significantly from the $800 originally expected.<\/p>\nAlternatively, it would cost the same $3200 to have brand new insulated steel doors installed. That means new hardware, new openers, and new doors, which effectively takes refurbishing off the table. So I could cancel the project and live with the crummy door that we can\u2019t close remotely, install the openers that may not work and have no warranty, or spend a lot more for the only \u201cgood\u201d option.<\/p>\n
I chose to get the new doors. It took about a month to get the parts, and they were installed today. I\u2019ve already noticed some pretty astonishing differences.<\/p>\n
Traditionally, on a cold night like tonight, when the 800sqft living room above the garage turns the heat down at midnight, the ambient temp would drop from 67F to 58F in about 30-45 minutes. With the new doors, I\u2019m writing this at 3am, it\u2019s 30F outside, and the room has lost only 3F. In fact, the garage, with no heat of its own, is still 58F. This is an incredible difference, especially since heat rises.<\/p>\n
So on the first night, I\u2019m already pretty happy with this out of control project. This seems like a substantial energy improvement. Sure, it\u2019ll take a long time for this to pay for itself, but that wasn\u2019t my goal in the first place. I just wanted my wife to be able to control \u201cher\u201d door when she leaves for work...<\/p>",
"date_published": "2021-03-13T13:24:37+00:00",
"date_modified": "2021-03-13T13:24:34+00:00"
},
{
"id": "eae20162-60c1-45a2-b618-20a3e52b1064",
"url": "https:\/\/thezaz.com\/blog\/xojos_best_switch_control_just",
"title": "Xojo's Best Switch Control Just Got Better",
"content_html": "
I said I'd do it ages ago, and I finally have. ZirconSwitch revision 4 is now available as an open source control. You can find the project at GitHub<\/a>, which has a zip archive for the full download in the releases section. The product page<\/a> has been updated too.<\/p>\nThis new version is built using Xojo's API 2, so it requires Xojo 2019r2 or newer. The design has been updated to modern UI standards, so if you don't like the latest flat design trends, well then I'm sorry to disappoint. The control is backwards compatible with older versions of the control, though control sizing has been deprecated. That's not a bad thing. Rather than three control heights to choose from, it now renders the full height of the canvas so you can size it any way you wish.<\/p>\n
And being open source, it's free for everybody. Have at it.<\/p>",
"date_published": "2021-01-06T18:52:21+00:00",
"date_modified": "2021-01-06T18:52:17+00:00"
},
{
"id": "d0b0829f-66d1-4d4d-a8d6-f05344d29287",
"url": "https:\/\/thezaz.com\/blog\/xojo_cant_compare",
"title": "Xojo Can't Compare",
"content_html": "
I will never fault a developer for their bugs, because it's part of the job. We are imperfect humans trying to teach perfect computers how to do their jobs. But sometimes the bug fixing process goes wrong, and that's what this is all about.<\/p>\n
The Bug<\/h3>\n
When a compiler has an arithmetic bug, it's embarrassing, but it happens. The bug gets fixed, and you move on with your life. When an arithmetic bug exists for 12 years without being fixed, that's disgraceful. When the developer categorically refuses to fix the bug, it's downright indefensible.<\/p>\n
Xojo has a problem comparing integers of differing types. This is because it tries to find a common type between the two types being compared, but there's no common type for many of the integer types.<\/p>\n
Here's an example of the problem:<\/p>\n
Var<\/span> FirstValue As<\/span> UInt32<\/span> = 4294967295<\/span>\nVar<\/span> SecondValue As<\/span> Int32<\/span> = -2147483648<\/span>\nIf<\/span> FirstValue > SecondValue Then<\/span>\n \/\/ Won't Reach Here<\/span>\nEnd<\/span> If<\/span><\/span><\/code><\/pre>\nThe block will never be entered because FirstValue and SecondValue are considered equal. In an effort to compare the two, the compiler converts FirstValue<\/code> into an Int32, which becomes the same value as SecondValue<\/code>. While some developers will say the two types should not be compared, there's two issues I have with this logic.<\/p>\n\n- My first grader can figure out which is larger. So should the compiler.<\/li>\n
- Xojo's target audience is people that don't understand the nuances of binary data.<\/li>\n<\/ol>\n
The bug becomes even more nasty though. Consider this code:<\/p>\n
Var<\/span> Value As<\/span> UInt32<\/span> = 4294967295<\/span>\nIf<\/span> Value > 100<\/span> Then<\/span>\n \/\/ Won't Reach Here<\/span>\nEnd<\/span> If<\/span><\/span><\/code><\/pre>\nIn a 32-bit application, this block will also never be entered for the same reason. Value<\/code> gets converted to an Int32 to match the type of the literal 100.<\/p>\nThe workaround is to cast the literal into a UInt32:<\/p>\n
Var<\/span> Value As<\/span> UInt32<\/span> = 4294967295<\/span>\nIf<\/span> Value > CType<\/span>(100<\/span>, UInt32<\/span>) Then<\/span>\n \/\/ You Will Reach Here<\/span>\nEnd<\/span> If<\/span><\/span><\/code><\/pre>\nIn a 64-bit application, comparing to 100 will work fine because Value<\/code> will be converted to an Int64 which has no problem containing the value. However the problem still exists in 64-bit applications once larger values are reached:<\/p>\nVar<\/span> Value As<\/span> UInt64<\/span> = 18446744073709551615<\/span>\nIf<\/span> Value > 100<\/span> Then<\/span>\n \/\/ Won't Reach Here<\/span>\nEnd<\/span> If<\/span><\/span><\/code><\/pre>\nA 64-bit application really just means it'll be harder to notice<\/em> the bug. It's still there.<\/p>\nThe Reports<\/h3>\n
When I original ran into the bug, I found Case #11935<\/a> and added my sample project. It was opened and verified 10 years ago, while I was working for Xojo. That really bothered me that we let this was issue slip through the cracks. Turns out the original report is even older. Case #2218<\/a> is the 12 year old original, but closed as by design. Aaron Ballman makes the case that changing how the literal is interpreted will lead to subtle bugs, and he's absolutely right.<\/p>\nThe issue at hand is that only solves the problem when comparing against a literal. The issue is the comparison itself, not the literal. That's why Case #11935 is much more interesting, as Thomas Tempelmann proposes a solution. I'm not a compiler engineer, so I'm not sure how viable it is, but it's a potential solution.<\/p>\n
In an effort to get some attention in the issue, I made a forum thread<\/a>, and boy did it get attention. A few other solutions were proposed, such as using basic logic or doing the comparison with infinite precision integers. Just to reiterate, I'm not certain how viable each solution is, but there are potential solutions.<\/p>\nThe Response<\/h3>\n
Xojo's response did not go as I expected. After 176 replies, they closed the forum post without any rules having been broken. Originally, their argument was that fixing the bug may break legacy code. It's a legit concern with any fix, but I can't think of any way that fixing a broken comparison would lead to broken code. I've asked Xojo for an example<\/a>, which they haven't provided. Nobody has been able to come up with an example of code that relies on comparisons being done incorrectly.<\/p>\nIf the bug were fixed, all of the above examples would begin to work, including the one with the explicit cast into UInt32. As much as I want this bug fixed, my intention is to prove Xojo right<\/em>. I want to see code that would work worse with this fix in place than without the fix. So far I have been unable to do so.<\/p>\nAs that argument fell apart, Xojo's reasoning was shifted to a combination of \"it's not a bug\" and \"it's not worth fixing.\" Logically, it can't be both. It's either not a bug and therefore can't be fixed, or it's it is a bug but not worth fixing. And because of that, I have to believe that Xojo's excuse is just that: an excuse.<\/p>\n
On top of that, all the bugs reported on the issue have been closed. This prevents them from being ranked, and Xojo uses rank to evaluate their priorities. Part of their logic is since it's unranked, it doesn't affect a lot of people. But since it's closed, it can't be ranked. This equates to a \"stick your fingers in your ears and pretending it's not happening\" tactic.<\/p>\n
The Conclusion<\/h3>\n
I believe the real reason they refuse to fix this bug is that they just can't<\/em>. Xojo does not have a compiler engineer anymore. They don't have somebody on staff who is able to write the unit tests, evaluate the behavior, make the changes, and test the results. I know even if I were still with Xojo, I wouldn't be able to.<\/p>\nThis is an embarrassing bug and indefensible response. Please spread this. Put pressure on Xojo to fix the bug. Make noise. Based on the closing of the forum post, Xojo's goal is to ignore this until we forget about it. So my goal is to get this into the eyes of potential customers. What customer would want a tool that can't get its comparisons right?<\/p>",
"date_published": "2020-10-02T16:08:32+00:00",
"date_modified": "2020-10-02T16:08:24+00:00"
},
{
"id": "6dae8c53-fccd-434d-a043-5a1068a5025d",
"url": "https:\/\/thezaz.com\/blog\/yo_where_my_session_at",
"title": "Yo where my session at?",
"content_html": "