Windows and Xojo

General
1

Yes. This is another Windows thread (TIAWT).

First off, our product is 100% Windows based and my Xojo experience on the Mac is limited to other projects that I work on, but the product that we sell and based our business off is Windows, so with that in mind.

The purpose of this thread, without question, is to bring to light that there needs to be more work on the Windows support.

I’m at the point now of having to decide to continue with Xojo or (God forbid) move to C# / .NET / WPF. And its becoming a harder sell to stick to Xojo.

So I’ll elaborate.

I realize that if we’re a 100% Windows shop, that we’re probably in the minority here.

And some would argue that we probably should use the native too set on the platform we’re generating revenue from – but we chose Xojo because of the fact that we wanted to avoid the distribution issues, cost and complexity of the Microsoft tools – which if people have been using them understand exactly what I’m talking about. Xojo provided (5 years ago), a very comparable development tool to VB 6.0, if not a better product that allowed you to build very much the same types of applications that you could with VB.

But here we are almost in 2014, and times have changed.

I look at the current apps for Windows and its clear that the apps we’re doing with Xojo (on Windows) are far from being “professional” looking, they run
slow – they flicker (yeah, yeah) and they have a far more “older” feel to them than their Mac counter parts which went through years of Cocoa development
to get them up to the point where they are following along with the path that Apple has set forth.

Windows in my opinion is now behind the curve, and its falling further behind with each new release of Windows. So much so now that its becoming a bit embarrassing trying to develop an app that “looks” like it should run on the current Windows 7 and 8 platforms.

When XP was the standard, you could get away with producing apps on Windows – they fit into that look and feel. Today? Not the case.

Xojo is lacking in performance on Windows

The Window’s side UI performs poorly, with lots of flicker (which is well documented here) and a very slow painting of objects on the screen compared to the native apps created in Visual Studio using XAML (I.e. DirectX).

Database performance is weak. If I do a SQL query in Xojo using OleObjects with ADO, its 50 and sometimes 70 times slower in my testing with the same query using C# and OleDb objects. That’s unacceptable.

Not having 64 bit executables also hinders performance for applications As most Windows business application deployment is now 64 bit, Xojo has to reside in a 32 bit “box”.

Xojo on Windows lacks extendability

Not being able to call a .NET DLL is hindering the ability for Xojo to be expanded to solve many of the issues or extend functionality – older “C” style DLL’s are no longer the norm on Windows and this is presenting problems with being able to create applications that are for recent versions of Windows.

Xojo apps lack the standard Windows controls and look and feel

Looking at apps on Windows 7 and 8… its not hard to see how Xojo apps stand out like a sore thumb. Further, not supporting the basic objects on Windows is becoming an issue. Why should I need to buy a grid control to “mimic” a component on Windows thats standard for Visual Studio applications. In fact, on Windows, Xojo should follow ALL the available Windows controls that are available to WPF / C# developers – and this includes allowing for the use of XAML.

The Xojo IDE looks like a Mac application

The Xojo IDE just doesn’t look or behave like a Windows application on Windows. I’m not saying “make Xojo look like Visual Studio”, but what I am saying is that the GUI has no resemblance of a Windows development tool and looks like Xcode on Windows.

Embrace MS API’s and technologies

Just like Xojo has embraced Cocoa, there should be an effort to do the same on Windows.

Not supporting simple things like ADO OleDb within the language and have it perform on par with its Window counterpart is really disappointing. When we have an ODBC plug-in, but given that most data access now is through OleDb objects, to see Xojo requires the use of OleObject – which is complied into the language and very slow – is really hindering Xojo.

I could go on here, I’ve listed some things… and I’m sure there’s things I’m forgetting!

I realize there’s only so much you can do. I fully support the efforts on the Mac and iOS as well, and even think the WE technology is interesting. But I think we get all that stuff at the expensive of Windows. Windows is really falling behind and this is going to be a problem for me as I decide to upgrade and move forward with Xojo.

I’d really love to hear that there’s at least a single developer dedicated to improving Windows. Someone dedicated to solely making the Windows side of the product better – that would give me some confidence.

2

Sounds to me like you have convinced yourself that XOJO is not the tool you need to be using… and are just attempting to get others to justify your rationalization?

Caveat : I am a Mac developer… however… those few apps that I have compiled under Windows 7 work just fine

3

I would not use Xojo if I were a 100% Windows shop. We often end up writing .NET helper utilities to take advantage of .NET capabilities and libraries.

4

Well to Gary’s point I think there is a big difference between working fine and being a modern Windows app.

It’s a LOT of work to get a Xojo app looking great on Windows. When you need cross platform Xojo is awesome but you do pay a penalty in not providing a modern experience.

5

There is.

6

Why bother selling a Windows [quote=48990:@Dave S]Sounds to me like you have convinced yourself that XOJO is not the tool you need to be using… and are just attempting to get others to justify your rationalization?

Caveat : I am a Mac developer… however… those few apps that I have compiled under Windows 7 work just fine[/quote]

To that point, why both selling a Windows version of the product if its not 100% where it should be, or better, not even 90% there.

I think it stands to reason that the Xojo folks see value in Windows – my point is simple. Then make sure its supporting Windows properly.

7

both = “bother”

8

Please give me an example of were Xojo lacks looking ‘great’ on Windows. It uses the API that is built into Windows so how can its appearance be behind? I think I can agree with you that the UI is slow but I thought that it was because the built-in API in Windows runs this slow anyway or are you talking about the actual IDE and not the compiled app.

9

Btw what .NET libraries do people often use to extend Xojo’s capabilities.

Thanks

10

I believe Xojo wraps the Windows SDK to create windows and objects – which is the “old” way of doing things. Microsoft has moved to DirectX and using XAML to render their screen objects. The difference is radical… I won’t get into why or what, but its a whole different way of doing the screen presentation.

The analogy would be Cocoa and Carbon.

11

Yes but that is a shame and one of the points I think Gary is making. I generally only develop for Mac but you would expect to be able to solely develop on Mac or Windows or Linux if you wanted and not see a difference in performance. Not everyone chooses Xojo for its cross platform capabilities (I didn’t)

I started using Xojo so I could develop for Mac. I came from Windows VB. If I was to develop solely for Windows I expect I would revert back to VB not use Xojo to develop for Windows only. That choice would be made because of all the bad press Xojo gets and my few tests on windows so I simply wouldn’t bother I would just use VB.

On the other hand if I was cross platform developing for Windows and VB I would use Xojo.

Back to the point I think I would go down the MS dev route if I was solely developing for Windows and the Xojo or Xcode route if I was solely developing for Linux. Sad as that may be that would be my choice at the moment

12

Xojo is in the process of rewriting the framework… maybe that will result in a more modern Windows implementation?

13

That is overstating the case.
We want to rewrite the Windows framework using .Net etc so we get all the nice features it brings to the table (like automatically double buffering etc)
But we have many other things to do first - like 64 bit support, move to LLVM, iOS, and several others

But this WILL be like moving from Carbon to Cocoa - in fact it may be bigger since there’s unlikely to be much code we can take from our existing Win32 based framework into .Net

15

[quote=49019:@Norman Palardy]That is overstating the case.
We want to rewrite the Windows framework using .Net etc so we get all the nice features it brings to the table (like automatically double buffering etc)
But we have many other things to do first - like 64 bit support, move to LLVM, iOS, and several others

But this WILL be like moving from Carbon to Cocoa - in fact it may be bigger since there’s unlikely to be much code we can take from our existing Win32 based framework into .Net[/quote]

And this is my fear… Waiting… its a huge project, which to me sounded like wasn’t started.

Norman, my suggestion is to elevate some of these pain points and “stop gap” some issues. You might consider during the 64 port as being a place where you can improve the Windows side to include the ability to call .NET components from Xojo.

I would say that if there was the ability to create a component in .NET and call that from Xojo. It would remove a lot of the issues I’ve highlighted above. A couple examples:

  • You could create a .NET component to “wrap” some OleDb calls and get far better database performance
  • You could create screen components to access objects otherwise not available in Xojo currently

By having just this feature alone, it would stave off a lot of the issues and buy Xojo a lot of time.

Gary

16

(can we edit posts?)… elevate = alleviate

17

Yay thankyou for bringing hope!!

18

Sounds like it would be a LONG ways off (I would guess 3-5 years) …

So far I have used Xojo mostly for in-house stuff. While a modern look and feel would nice, for that it’s not very critical. For those that sell apps externally, I could see that i could as a BIG issue that gets bigger every year…

Since Xojo’s main selling point is X-Platform, and I think that mainly is Mac ↔ Win, can it really wait that long without hurting sales?

As I said, right now it’s not critical to me… but with over 12 years with this product so far, I want it to stay around!!!

19

To be honest, I can deal with this problem, as along as 64 bit support and other stuff gets implemented.

20

Not while we already have 4 or 5 really huge projects on the go

I’m told this is technically possible but I’m not the architect so I really can’t say much more as I’m sure, like always, there are implementation details.
It’s certainly on our radar though.

21

If you look at the Carbon to Cocoa transition that took about 18 months (perhaps more) worth of effort. Multiple developers and a lot of work, testing, and rework. If the transition to .NET is an even bigger project… Well, draw your own conclusions on timeframe and that’s assuming they’ve already started it before (or concurrently with) the 64 bit and LLVM work.