Mac Xojo versus Windows Xojo

General
1

Hi all,

I’ve been developing an app using the Mac Xojo Desktop edition. This is my preferred environment and I do plan to build the app for Windows and Linux.

The other day my Mac was at home and I had a Windows laptop and a few hours to kill so I downloaded and installed the Windows Xojo and licensed it. I got my source from github and was going to do some development work.

The first thing I noticed is a bunch of resources (image files etc) were reported as missing. I suspected this was a github thing and I could re-add them later. They really were not used yet.

I began working on various windows and made a few changes here and there in a few hours I had. I could compile and run the project just fine on Windows.

I checked the changes into github. A day later, on my Mac I pulled down the latest changes and opened the project and building popped up a BUNCH of errors. In looking at the changes for the revision pushed to github after the windows edits that a bunch of things in the App were changed that I know I didn’t change.

For one, the “opening” event was completely removed. Many of the App properties that things relied upon were completely removed. The thing is that for me to manually remove all of these things would have taken quite a few very specific user actions which I know I did not do.

I have to say this experience has caused me to lose confidence in being able to “cross-develop” a project between say Windows and Mac. By cross-develop, I mean open and use the project for changes and building between the two OSes.

Is this just a fluke or is this expected and people using Xojo stick to only one build environment?

Thanks in advance - Mark

2

Hi @Mark_Holbrook

Are you using the same Xojo release both on macOS and Windows? Is the project API 1, API 2 or a mix of both?

Do you have some public project published on GitHub so we can try it both on Windows and macOS?

1 Like
3

Hi Javier, thanks for the response. The project is proprietary to the company I am contracting with. I am not at liberty to share it.

Let me confirm the version numbers but I do believe they are the same. I will post back here what I find. Unfortunately both computers are in different locations.

Mark

4

If the errors are about pictures, it comes from the fact that Xojo uses absolute path. These paths are quite different on Mac and Windows.

1 Like
5

Hi Michel, Part of the problem was missing images and the paths could totally explain that.

The removal of events and props from the App object is the real concern. I’m still checking it out and will post back my findings here.

6

If your images are stored in the repo, Xojo will still find them despite the absolute paths. My guess is these images were dragged into the project on Mac, but not actually moved into the repo first, so they didn’t come along.

But when done right, images work just fine cross platform.

7

Thom, that is what I am hoping for. My concern is not the images. Those probably suffered the fate you describe.

My concern is the removal of properties and event handlers from the App object. That I know for a fact I did not do. It just seemed happen.

I did get a message in recalling the process that something needed to be upgraded to Desktop and I allowed that to happen. Maybe that was the issue.

I’m going to try and duplicate this behavior.

8

Upgrading to Desktop is the main cluprit for the loss of events and propertties.

This is part of Xojo’s API 2.0 plan. You may need to get direct assistance from Xojo engineering to ensure that everything is in Sync.

9

Sorry, I didn’t really have anything to add to that part of the conversation.

10

And:

the “opening” event was completely removed…
let us think you are using a pre-2022 Xojo version on macOS.

à priori, no need to check the Xojo Windows version: you certainly downloaded the last (current) one: Xojo 2022r1.1.

HTH.

1 Like
11

2 comments:

1- My experience with .xojo_images and working with a team
Xojo imageset saves the information with a full path and relative path, like this:

FullPath = D:\projects\project1\images\myimage.png
PartialPath = images\myimage.png

Of course, this is a Windows path. If I pull Git into a Mac in /Users/MyUser/MyProjects/myproject1/
the image will be saved to:
/Users/MyUser/MyProjects/myproject1/images/myimage.png

and that is not a problem. Xojo will try the PartialPath and will find the image.

One problem is when a new project is created from this project that uses the same image, the PartialPath could change to:

PartialPath = …\project1\images\myimage.png

if you are the user using Windows, your project will load correctly because the PartialPath will find the image.

If you are the user using Mac, your project will not load the image because you set up the project folder name of the first project to ‘myproject1’ so this path:

PartialPath = …\project1\images\myimage.png

will not find the image.

Make sure your images are in your project and your .xojo_image point to the PartialPath within the project to avoid problems with Windows/Mac and even from one computer to another (for example in the other computer you don’t have project1)

2- some users on our team use Windows, others use Mac, we work with the same projects all the time and we haven’t seen this problem (deleted properties).

We try to check all the changes before we push to Git, if we know that we changed 5 things and we are about to push 20 or 50, we first need to review what was changed and why.

Depending on the software you use for source control you can easily see what changes were pushed when you worked on the Windows machine. You then can find what changed and just need to remember what was done in Xojo. Maybe update to Desktop controls? Maybe update to API2?

12

This is not or mac or windows thing. It is a weakness in the way Xojo handles external images.

We run into this almost all the time when two people with identical mac work in GIT.

You have to chase down the images and reconnect them in the dialog that opens when the code is first loaded into he IDE

1 Like
13

@Michel_Bujardet: really, you like the fact that the IDE is broken? :wink:

14

From where is this coming from ? ? ?

Fact is, I have been using RB turned Xojo for over a decade on both Mac and Windows without major issue, besides pictures that need to be pointed to. I would not call that a broken IDE.

Now, if you want me to howl with wolves that the IDE is broken, sorry, I don’t think so.

1 Like
15

Broken?.. Well let’s just call it significantly suboptimal!

I stayed on 2019R1.1 even though I am on Monterey (thanks Norm!)
but I was seeing some oddities and I was not sure if they were due to using 2019R1.1 on Monterey so (while staying API 1 and 2019R1.1 compatible) I switched to using 2022r1.1…

But it added an additional headache… the color picker… I needed to use it a lot for this project for inserting colors in code… I never knew when or WHERE the color would show up in my code… Frustrating to say the least! The colorpicker in 2019r1.1 works just fine on Monterey…

I was also disappointed the autocomplete still would not work for some things without using the full namespaced name in the DIM statement!

It would work for the variable name, but frustratingly, not for it’s components!

While autocomplete works a bit differently than in 2019r1.1 it still has that limitation 3 years later!

And then there is the “help” … I wind up keeping 2019r1.1 open anyway to to use it’s local language reference…

I think I may go back to 2019r1.1 full-time…

Luckily I still can, although I came close to that not being the case out of habit…

Although I came close few times, I managed not do a Save As which would have made the code incompatible with 2019R1.1 (I do Save as to “fork” when I am making som big changes I am no sure will work out - as a "Citizen developer, I don’ use source control)

I remembered to go into finder and copy the project so it stayed 2019r1.1 compatible…

As I said the IDE is significantly less than optimal IMO for sure!!!

-Karen

1 Like
16

Funny how this reminds me of discussions about the Xojo IDE from people nostalgic or the RB one.

Seems a lot has to do with insisting to use API 1.00. Dim is no longer the norm.

17

Autocomplete and color picker issues have nothing to do with API 1. The “Save As” compatibility issue is the only one that is.

In any case I still keep getting momentarily lost in the Xojo IDE Navigator. That has not changed between API 1 an API 2.

Even Xojo inc says they realize the current IDE design has significant usability issues and are working on changing it yet again. I think that means even they realize it is significantly suboptimal!

BTW DIM is not deprecated, so why pick on it?

-Karen

2 Likes
18

Nobody said deprecated. Var is the new preferred way to declare variables.

I suspect the navigator will not be going away. Xojo’s high-level layout is pretty standard these days. The roadmap’s navigation improvements likely mean a change of behavior, not a significant redesign.

19

Screen Shot 2022-07-23 at 16.50.14

20

I just observed you liked the post above mine (Jay’s post) and I was just “joking” about that since the post is about weakness in the IDE.
Sorry for having been misunderstood.