Building for macOS issues

Hi
I’ve worked on a analysis application using Xojo for some years now and the main target have been windows. The development has been done in the IDE for windows. The application have been quite competent and it starting to sell itself to engineers I’ve worked with during the years. Now I’ve got a customer that using the macOS computer and I’ve thought I could support him with a macOS built version. At the first steps during this path, it seemed to be easy to support him. The most part of the application was running fine, but later on I have run into some real tricky difference with the macOS version:

  1. If you call a canvas.refresh method to update for instance the zoom level during an contextual menu action, the MacOS application will not trigger the canvas paint event. On the windows platform it works really fine. The ugly work around is the move all the paint code from the event to a method and paint into a new memory item for the macOS system.
    Is this an error in the macOS compiler?

  2. If you want to show and move a help window from the canvas.mouseDrag event, I found that setting the window.visible = true will not make the window visible on the MacOS but it will on the windows platform as the documentation tells us. The work around was to add a call to the window.show method in the macOS application.
    Is this an error in the macOS compiler?

  3. The FolderItem.NativePath for a folder will on the macOS return a string without the last “/”, but on windows the string contains the last "". Interesting difference! From my point of view I want the last “/” to be present in the string on macOS to make it directly useful when adding file names to the path. The work around is a FolderItem extension method GetNativePath as:
    #if TargetWindows = true then
    return fi.NativePath
    #else
    if fi.IsFolder = true then
    return fi.NativePath + “/” //Needed for macos, linux is unknown
    else
    return fi.NativePath
    end if
    #endif

Is this an error in the macOS compiler?

  1. Passing a string containing &h0A (LF) characters for multi row view in a TextArea.text will give multi row view in the windows platform but not in the MACOS system. For macOS systems you need to first convert the string to UTF8 form in order to get it correct.
    Interesting difference!

  2. The trickiest difference I found so far, and this is an issue I need support on, is the difference in the event trig order when it comes to contextual menus in a list box. In the windows system when you right click on an item in the list box, the mouseDown event of the list box will be fired first, before the event for building the contextual menu itself. This makes it possible to determine the row index for the contextual click and to make the action method know which item in the list box that was clicked. On the macOS the contextual menu event and the action event is fired before the mousedown event of the list box when using control+click. This makes the application to malfunction. Using a two button mouse on the macOS system will surprisingly switch the event firing order and it seems to work. The draw back with the two button mouse is it will not fire the contextual events in a canvas placed in a tab area in the tabpanel. You must use the control + left click in this case. My question is how do I solve this to always get the correct event order with the mouseDown event first and working contextual events in a tabpanel canvas with the same user actions?
    Is this solvable or shall I drop my attempt have a macOS variant of my xojo application for windows?

I testing the mac application on a mac book pro with MacOS version 11.5.2.

Regards Håkan N

You issues sound really minor. Please do a topic for each one here on the forum and show your code.

Refreshes are tricky on macOS because the OS controls them. However, a refresh should always be done.

Windows always need to be shown with .show.

1. If you call a canvas.refresh method ...during an contextual menu action, ...move all the paint code from the event to a method

Are you drawing to the canvas in the contextual event?
Yoy should only do that in the canvas paint event.
That event will fire as soon as the contextual menu event finishes.

  1. The FolderItem.NativePath for a folder will on the macOS return a string without the last “/”…I want the last “/” to be present… to make it … useful when adding file names to the path.

Don’t do that.
If you need a child of the item fi, then get it using ch= fi.child(“childname.ext”)
Works everywhere.
If you THEN need a full native path for something else, you just ask for ch.nativepath

Is this an error in the macOS compiler?

No.

For macOS systems you need to first convert the string to UTF8 form in order to get it correct.

Xojo has a function to convert the line endings for that purpose.

In the windows system when you right click on an item in the list box, the mouseDown event of the list box will be fired first, before the event for building the contextual menu itself.
Using a two button mouse on the macOS system will surprisingly switch the event firing order and it seems to work.

Advise people to select the row they want, then right-click to access the extra functions.
Or add a ‘button’ to the row that brings up your contextual stuff.

My question is how do I solve this to always get the correct event order with the mouseDown event first and working contextual events in a tabpanel canvas with the same user actions?

Try checking for if IsContextualClick then

Is this solvable or shall I drop my attempt have a macOS variant of my xojo application for windows?

Sounds pretty simple to find a work around for.

  1. MacOS optimizes drawing to happen next time the event loop runs. Make sure your code runs via timer to allow a few milliseconds to redraw.
  2. Make a sample project and report as issue, please.
  3. Don’t do paths like this. Use FolderItem objects and .Child() to append file name. Picks the delimiter automatically internally.
  4. Please show details. Adding Chr(&h0A) to a text area should work fine.
  5. macOS and Windows work different here. MacOS allows you to open contextual menu for a different row than the selected row. You can query row from X/Y:
Function ConstructContextualMenu(base As DesktopMenuItem, x As Integer, y As Integer) Handles ConstructContextualMenu as Boolean
  Dim row As Integer = Me.RowFromXY(x,y)
  
  System.DebugLog "row: "+str(row)
End Function
2 Likes

I’ve always wondered why the x parameter is needed in this function :man_shrugging:.
A vertical row would rather be a column…

Yes, for the future. Just in case you ever get a 90° rotated one…

Oh, I see.
But then, if everything would be prepared for future possible cases, each single available function in Xojo would take next-to-infinite parameters. I mean: why preparing for that as it’s unlikely to happen (and would probably be not useful)? And even then, a new function later would be more appropriate, imo.

That was more like a joke.
The guy who created the function added X and Y.
And now we have to carry that over until a future control has a new method.

Oh, sorry. So typical of me to take something straight…
I now appreciate the joke as it is :slightly_smiling_face:.

Granted.
Thanks for your reply.

That’s a 10 years old bug that was not fixed yet:
https://tracker.xojo.com/xojoinc/xojo/-/issues/29638

Thank you all for your comments.

I will look into the suggestion to move the row determine part from the mousedown event to the constructContextualMenu event to solve the different event order difference.

For the refresh part the documentation is clear that it shall activate a paint event directly. If this difference is caused by the macOS behavior I think the documentation shall be updated to reflect the difference.

For the nativePath part, I think properties and methods like this always shall produce the same result independent of the platform in concern. to avoid issues.

In general it should be a great service if there is a collection of this kind of differences between platforms to make it possible to be aware of these things before running into time consuming dubug sessions. This might already be present somewhere in documentation. If that’s the case I will appreciate a hind where I can find it.

I have screen shots for the textArea issue that I can post.
Is it possible to post pictures through on this forum?

/Håkan N

THere is no issue here excepted a knowledge one:
You do not have to care about that since to use a child of a NativePath, you use… f.Child(“Son.txt”.
Appending a child name to a NativePath is a NoNo (I do not even know if you can create a FolderItem this way.

.Child and .Parent are what you need to use to go to the up FolderItem object or down FolderItem object. (navigation in a folder).

Paste the image in the Clipboard directly in this Forum Edit area to see it (on the right pane)…

And you would be wrong. Concatenating paths has never been recommended and never been supported cross platform. Use the methods that are provided and which are cross platform. NativePath is exactly what it says, native to the OS. It is not going to work cross platform.

1 Like

And the documentation is perfectly clear on the subject:

https://documentation.xojo.com/api/files/folderitem.html#folderitem-nativepath

Actually… the reason it takes x & y is that the underlying framework call on macOS takes both and returns row and column at the same time, and because Mac was the first framework… it’s never been changed.

1 Like

Hi again
Thanks for all feeedback.

Here is my pictures when trying to view a string in a textArea on MacOS:
The first one is the binary content of a string named hs ( var hs as string )
there the chr(&h0A) is highlighted.
image

After setting the TextArea1.text = hs without any encodings I get the following on a MACOS system there the &h0A byte is changed to &hEFBFBD highlighted:

image

On a windows system are the &h0A not converted.
The string data blocks are read from a binary file from an oscilloscope containing both string data and binary double data. The string data blocks are added together in xojo by adding the chr(&h0A) in between to form the hs string.

I have study the suggestion to solve the event order issue and it seems that I can’t do the graphical behavior i want on the macOS system due to the difference i the event order, see the picture below. The suggestion given solved some of my issues and was very helpful. Thanks alot.

image

On a windows system the contextual event order is equal between a mouse and a track pad command.
On a macOS system there is a significant difference between contextual event order from a mouse and a track pad. Both event orders are different from the windows system.

The graphical behavior I have in the windows application is a list box, in this case full of loaded files, there the multi selection of items in the list box shall be preserved through a contextual menu command. The row contextual clicked shall be highlighted in the list box before the menu occurs to show the user which item was clicked to make it possible for the use to abort the contextual menu if necessary. This is possible, in the windows system, because the first set of PaintCellBackground event and the PaintCellText event is fired before the constructContextualMenu event. In the macOS system they are fired after instead.

Is this impossible to do in a macOS system or is there a way to fire the necessary events before the constructContextualMenu event on the macOS system by code?

/Håkan N

What I’ve found to work in all situations on MacOS is to construct and display the contextual menu in the MouseDown event using separate methods. Something like this:

if IsContextualClick then
  
  contextMenuSelectedRows = ContextuallySelectedRows(x,y)
  me.Invalidate
  
  dim baseMenu as new MenuItem
  ContextualMenuConstructor(baseMenu,contextMenuSelectedRows)
  dim hitItem as MenuItem = baseMenu.PopUp
  ContextualMenuAction(hitItem)
  
  redim contextMenuSelectedRows(-1)
  me.Invalidate
  
  return true
  
end

return false

I’m not actually sure why this isn’t blocking and allows the paint events to fire while still displaying the menu, but it works.

1 Like

Many thanks Jared, you saved my day.

You showed the trick to make the contextual clicks consistent between mac and windows platforms independent from track pad or mouse and generate an equal graphical experience for the user. Good work!

Have you tested it on the linux platform too?
This is an excellent example for xojo to use among the example projects.

Again Many thanks Håkan N

I’m glad to hear that this works on Windows as well.
I haven’t tested on Linux either, only MacOS.