10 years ago people came to me asking for Windows apps with the side benefit of getting a Mac app too (to satisfy that Mac ■■■■ in the corner). Now, they come to me for a Mac app with the side benefit of getting Windows users. And in the past year I’ve done more Web Edition work than I have desktop.
Times, they are a changin’.
For me, I care about the announcement share:
“Native, Multi-Platform
Xojo apps don’t have an interpreter or virtual machine - they’re compiled to machine code for fast execution and the protection of your intellectual property. Xojo uses native controls so your app looks and feels right on each platform. Development is multi-platform as well. Create your project on your favorite OS and then build it for any platform Xojo supports.”
“You can deploy to OS X, Windows and Linux.”
So it must work 100% well on all those.
No more. Equal. Linux too. When iOS comes out, the same. 
[quote=24926:@Rick A.]
“You can deploy to OS X, Windows and Linux.”
So it must work 100% well on all those.[/quote]
Which it doesn’t.
When using Xojo to produce Windows desktop software, one does not even come close to the quality which is standard nowadays, when using C# or VB .Net, despite of using all kind of hackish workarounds in order to avoid flicker.
But yes, one can create Windows software and if your customers think the quality is good enough - yeah, then maybe: why bother?
Linux desktop programs are even worse. (But who writes Linux desktop software when there is a 1% market share only?)
So currently I’m using Xojo because I can create Cocoa apps which satisfy our in-house demands on quality and functionality, AND i can create Webapps, AND I can create console programs running on a Linux server.
Me? Why I bought Xojo? Because I can (could?) write perfect cross-platforms programs (at least for the 3 platforms announced). Well, at least this is the message the marketing passes. And If I write a concept in OSX, and I can compile it for Linux, and my clients like the idea of not needing OS licenses for 7 machines, why not?
Reading those statistics at the top of this thread, it once again made me think how little the importance of Windows is reflected in the last year’s efforts of Xojo (formerly Real Software). I give an example:
What I gain in speed of writing X-platform software with Xojo I probably loose again while working around all flaws and shortcomings of Xojo Windows programs. To decrease the unspeakable flicker I had a closer look on how certain MS Outlook versions behave on Windows 7. For instance when resizing Outlook, there is no life-resizing, but just a frame which is displayed during the drag. Same for splitters: just a rectangle area which is moved and only at the end the areas snap in to the new position.
In simple Windows programs we do not have to mimic such behavior, because the common suggestions for avoiding flicker will do it. But if we want to use PagePanels, ContainerControls and tons of controls in it - in complex applications - then we need to find a flicker-workaround. Otherwise users will simply not accept it.
Now, in Windows a User can set himself whether he wants life resize for all applications or not. In order to switch it on and off just for this Xojo Windows app, I’m using declares. In a Window resizing and resized event handler, I switch window life resize temporarily on or off, like this:
Sub LockWindowUpdateOn(Control as integer)
#if TargetWin32 then
Declare Sub LockWindowUpdate Lib "user32" (ByVal hWnd As Integer)
LockWindowUpdate Control
#endif
End Sub
Sub LockWindowUpdateOff()
#if TargetWin32 then
Declare Sub LockWindowUpdate Lib "user32" (ByVal hWnd As Integer)
LockWindowUpdate 0
#endif
End Sub
This is just one of the workarounds (Just an example, there is more involved and to do here).
It took me a lot of time and experimenting, just to find out that there IS a severe flicker problem with Xojo and Windows and that there are plenty of do’s and dont’s which were nowhere mentioned in marketing materials (of course) or in manuals or tutorials. You first have to run into the problem and then eventually find some hackish workarounds in the forums.
Which leads all the RAD, ‘rapid’ marketing yadayada ad absurdum.
And this has been like this for the past 5 years (and probably longer) and Windows remains neglected, despite of the fact that TODAY we have 90% of the desktops running Windows.
Well, I guess it is a business decision which just has to be accepted. But yes, in relation to Windows programs, I am disappointed with Xojo.
Oliver, I understand your frustration, been there when Xojo hasn’t implemented for the Mac when we needed them. I recall having an argument with Geoff when Apple went Intel and my competitors who had gone intel got a speed boost, and my app didn’t perform so well. There have been other times too, where I’ve had to learn some Obj-C to accomplish some tasks. although the move to Cocoa has helped tremendously with that.
Here’s what I would suggest, if you have some specific cases you want fixed, let us know. I’ll add (some) of them to my top cases and if other developers can do so, perhaps it will help.
The other thing I suggest is perhaps you could start a thread and post all the work arounds you’ve discovered, maybe even a demo application so that other users can benefit too. If you wanted, you could probably charge for it or ask for donations.
Xojo’s biggest problem is Apple & their users (me included). Apple change their OS so damn frequently (and connectivity on their hardware) that it can be a challenge for Xojo. If Xojo doesn’t keep up, it means that Xojo apps are either not as compatible or capable as apps built with Apple’s own tool, which means that people like myself need Xojo to keep up, and yes I’m responsible for complaining. You know what they say about the squeaky wheel?
On the other hand, Windows hasn’t changed that much, they slap a new lick of paint on it every few years and provide tons of compatibility options, I heard that with the right settings you can still run Windows 95 apps on Windows 8, try running a Mac app from 1995 in OS X 10.8, ain’t gonna happen.
Thanks a lot, Sam! This forum with people like you make Xojo really special.
I was thinking already on how I could summarize the solutions I found and make them available. So for instance I am paying for the the Swiss domain xojo.ch, which I thought could eventually become a place for a Swiss User Group. (Right now it is routed to xojo.com, and if Xojo Inc would take this as an offense, I’m ready to transfer it to them at any time, for free).
For myself I made a collection of stripped-down projects, which demonstrate solutions for various issues. Those could be made available there. And more - but my problem is spare time. And I have doubts whether just another website with a handful of more or less useful projects is really needed …
Maybe it is still better to post answers here, once issues come up.
Anyway, I wished Xojo IDE would contain more help and features, in order to overcome the Windows flicker issues, like Windows specific properties, which allow for switching life-resize on and off (so one has not to dive into the scary world of Windows declares).
You’re welcome, we’re all in this together and the more we can work together the better we’ll be, even if Windows doesn’t mena much to me at the moment
I thought the same thing, and then I decided that I would post a small article here, after all it’s where people will look (one hopes) and saves me managing a site elsewhere. Indeed spare time is an issue, but I also secretly hope that if I post code freely available, it might inspire Xojo techs to implement that function/feature 
Well, there may be a market for developers who are willing to pay a little cash to do things correctly. For instance supporting Retina on the Mac, can be done easily, but to do it correctly (IMHO) takes more work, so I started to sell the code to those who want to do properly but don’t want to spend the time implementing such a solution. While I’m not a millionaire from it, it’s nice to know that there are people who do value what I can offer.
As for declares, I personally think that this is something that everyone should learn, there is so much power lying awaiting in OS toolboxes, declares take your app to the next level.
I’ve been doing some work on Windows lately using Visual Studio and C# (No choice on this as I have to create some code that runs against a .NET platform and call .NET libraries). This project had me learn the WPF (Windows Presentation Foundation) mechanism called XAML.
One of the things I’ve realized is that Windows has a completely new rendering engine which is no longer based on the older GDI. Today, its based off the DirectX API and is wrapped in a technology called XAML.
With this comes faster rendering and painting, far better support for newer graphical objects that are more advanced and far more forward looking with the Windows interface – Metro, and all the “cool” look and feel things are supported.
I think like Cocoa, it might make sense for Geoff and the gang to revisit Windows from the GUI perspective and support the new rendering engine. It appears that from where I’m sitting, the Xojo UI Framework for Windows has not only been “suspect”, but its now fallen behind times and you can’t build an app on Windows that “looks” modern anymore.
.Net is certainly one of the things we have on our TO DO list and there are a bunch of things it would enable.
We need to deal with the existing big items on the list like LLVM, 64 bit, iOS etc first though.
Our company scrapped Xojo on Windows after a few hours of evaluation. Just to many things missing compared to
the other languages we evaluated.
I’m curious, what features are missing that changed your mind about Xojo?
Alwyn,
We do a lot of scientific calculations at work, we needed a programming language that supported
the ability to write assembly language, access the GPU for graphics, calculations and required that
all controls were rendered using the GPU or CPU.
Some of our calculations can take up to 1 week or even longer, by using the GPU we can
shorten the time considerably. Sometimes we have thousands of copies of a calculation
in parallel which are being computed. We also create graphics that simulate some of
the calculations so that is also taken into consideration.
The compiler must also be able to create 64bit executables and have very good optimization.
When debugging we also need to be able to see the assembler code on break points.
I have a product that sells well on Windows, albeit, its not terrifically graphical in nature, but it works well.
Graphically, I think moving towards the newer DirectX framework will get you access to the newer components.
But honestly, thats really not a priority (for us) as the product doesn’t do more than the typical CUA interface
stuff – we’re not doing this complicated GUI by any means so what we have works and does the job.
My biggest complaint with Xojo / RB on Windows is really more about performance of things that on C# and .NET are much faster.
It’s making us wonder if we need to “port” back to that platform. For example, we’re using ADO COM to talk directly to SQL Server from Xojo. This appears to be about 10 - 15 times slower on simple queries with lots of data. On C#, using the bindings for ADO through their database interface – and its REALLY fast.
I’m hoping the move to LLVM will improve things, but I also hope the folks at Xojo bring on a Windows expert to take a look at the platform so it can be better served on Windows.
I’ve started a case <https://xojo.com/issue/28733> to formally ask for .NET to be considered on the road map. Please support the case if you agree.
[quote=26002:@Diper Duck]Alwyn,
We do a lot of scientific calculations at work, we needed a programming language that supported
the ability to write assembly language, access the GPU for graphics, calculations and required that
all controls were rendered using the GPU or CPU.
Some of our calculations can take up to 1 week or even longer, by using the GPU we can
shorten the time considerably. Sometimes we have thousands of copies of a calculation
in parallel which are being computed. We also create graphics that simulate some of
the calculations so that is also taken into consideration.
The compiler must also be able to create 64bit executables and have very good optimization.
When debugging we also need to be able to see the assembler code on break points.[/quote]
You want Xcode or something more like that where you can dive into the assembly
[quote=25994:@Diper Duck]Our company scrapped Xojo on Windows after a few hours of evaluation. Just to many things missing compared to
the other languages we evaluated.[/quote]
I think if your company doesn’t need cross platform application, just stick with what is best on that platform. For our company, we do cross platform application and XOJO is the best i have used.
[quote=26002:@Diper Duck]We do a lot of scientific calculations at work, we needed a programming language that supported
the ability to write assembly language, access the GPU for graphics, calculations and required that
all controls were rendered using the GPU or CPU.[/quote]
Can’t help on Windows, but on the Mac version it’s possible to write CIKernel code directly in Xojo and have Apple’s Core Image execute it for you on the Graphics hardware. If Microsoft offer high level APIs they might be accessible in Xojo via declares, but for directly writing assembler code Xojo…
I don’t think the desktop will ever entirely disappear. Although some devices are becoming so powerful that they can run very complex applications, there are still a lot of applications that require the most powerful hardware available, with the fastest storage available.