Updating my apps to latest XOJO 2019 r3

I’ve been using 2018 r2, and I finally had some time to look at updating. I have all the latest versions up to 2019 r3. I know I’m late to the dance, but I need to catch up.

  1. When I go to compile I’m seeing 3 errors (but many instances of them). I see that we’re no longer using “absolutePath” and should now use nativePath? Is that changing from colons to backslashes? There are quite few instances of this one.

  2. Also I’m getting this error in my Canvas:

Parameter "format" expects enum Picture.Formats, but this is type String. If Picture.IsExportFormatSupported(Picture.FormatPNG) Then

The code for the above error in the Canvas is:

If me.Backdrop <> Nil Then // Get a temporary file to save the image to If Picture.IsExportFormatSupported(Picture.FormatPNG) Then f = f2.child(captionName) if f <> nil then // Save the image out to the file me.Backdrop.Save(f, Picture.SaveAsPNG) end if End If

Not sure if that’s native to XOJO or from MBS plugins. How do I fix that?

  1. And another one is the macType and macCreator:

prefsModule.saveas, line 203 Type "FolderItem" has no member named "macType" f.macType = "MCPT" // Use your file Type

Is this no longer required? Or how should I replace those bits of code? That might affect older files.

It’s not always that straight forward, even though it may look like it. The most reliable path forward would be to release a minor update with 2018r2 that re-saves all paths as NativePath so that your major upgrade can read them. This may not be doable in every situation. I think others have written converters, but I don’t have anything handy.

Update this to the new Formats enumeration. Picture — Xojo documentation

You can remove these.

Thanks, Tim. Hopefully I can get my apps back up to speed soon.

+100

I also learned this the hard way.

Sorry to hijack this thread. =)

I’d like to know how to REPLACE the MacType, MacCreator, MacDirID, and MacVRefNum methods and setters that got removed in 2019.r3. FIles still have these attributes on a HFS disk. In the answer to Patrick, someone says “you can remove those” but in reality you can’t. My app in small part reads these attributes.

What are you doing with the old stuff? For MacType and MacCreator you have the UTIs, for MacDirID and MacVRefNum you should use the newer APIs for folderitems.

Well… concerning MacType and MacCreator, my app in part can deal with older files created in many decades old Mac’s. Back in the day, that was the 100% preferred Mac-way. Name extensions were barely used and files were always Typed. My app (in part) features identifying these files (of course on a HFS, which are plenty around) and then working with them. A good example is AIFF files; a client can bring in a whole folder of files called (say) ‘Trumpet’ ‘Trombone’ ‘Sax’ - and they are only identified as AIFF because the FileType connected to them via the HFS disk is ‘AIFF’. In the past I did this via f.MacType. Now, how do I do it? (Same with MacCreator.)

I mean, we have new Mac’s, new macOS, etc. But it doesn’t mean we don’t have or shouldn’t be able to deal with old files. macOS still has to support HFS disks, so I never understood why Xojo deprecated MacType and MacCreator - macOS still must have modern non-deprecated API’s to access these. It will be years until Apple says “this new OS will not support reading HFS disks anymore.”

I’m just looking for a substitution method (even MBS) on finding the FileType and CreatorCode for a file.

Regarding DirID and VRefNum is kind of similar, although way way way less necessary. I just included that request because it’s all HFS-related.

MacType and MacCreator haven’t been in use for the last 10 years or so. Read up on UTIs: http://documentation.xojo.com/topics/file_managment/understanding_uniform_type_identifiers.html

Being a big Beatrix fan =) but I have to tell you to re-read what I wrote.

I’m not talking about current apps and current files. I’m not talking about what SHOULD BE and how an app should CREATE a file. I’m talking about dealing with admittedly old files - ones with no named extensions and only file-type identified by the FileType attribute in the HFS disk in which it resides. UTI’s are AFAIK completely irrelevant to what I’m speaking of.

For an example, let’s say I acquire a Folder item like this (forgive the code):

For i = 1 To fParent.Count
f = fParent.Item(i)
// the file is on a HFS disk and has FileType and CreatorCode attributes. How do we get those attributes?
Next

[quote=493902:@Garth Hjelte]Being a big Beatrix fan =) but I have to tell you to re-read what I wrote.

I’m not talking about current apps and current files. I’m not talking about what SHOULD BE and how an app should CREATE a file. I’m talking about dealing with admittedly old files - ones with no named extensions and only file-type identified by the FileType attribute in the HFS disk in which it resides. UTI’s are AFAIK completely irrelevant to what I’m speaking of.
[/quote]

Part of a UTI IS A “OS Type” code which is the old mac type :slight_smile:
the creator code is about the only one that has NO modern equivalent

It isn’t reasonable to read EVERY FILE to see what it is. That’s the point of file extensions or file types or UTI’s.

Great - ok, so how do I get a UTI of a Folder Item in Xojo? I don’t see any “UTI” property (not in Xojo or MBS), and the page Beatrix offered was just general Mac-specific information on UTI’s. In the section Usage In Xojo, it just lists 3 things:

How to attach an app with a UTI (not my question or need)
UTI’s in Clipboard contents (irrelevant too)
UTI’s for Spotlight querys (also irrelevant)

I just want a replacement function to get the MacType of a FolderItem. I knew f.MacType was deprecated for the last 6-8 years, but it didn’t erase my need for it.

a. Is it reasonnable to have so many fotems in a folder ?

b. You seems to need to do that, and you do that only once so, why do you care ? And I do not think you have another solution in your case.

Is it just for you or for customers ?
Is it in a locked storage (CD-DVD-BR…) ?
Is it in a web file server ?

Nota: even if the items have extensions, reading this “property” is a good idea (some people change item extension without knowing what they do, the software have to be sure before using item contents).

Now, if someone comes with a different solution (I’ve done that - the above - with AppleScript before REALbasic 1 was in alpha).

define the UTI in your app (its probably imported) with the properties including the OS Type code
Then a folderitem has a TYPE
Because a UTI might match on extension OR type OR mime type etc etc etc UTI’s can match a little more broadly than the old MacType code

Thanks, that takes me a little ways there, but I found a direct solution, MBS-dependent, but then everyone should use MBS IMO.

Again, I don’t see why Xojo didn’t simply inject whatever MBS is doing and updated the MacType and MacCreator methods. Look, I understand that old TECHNOLOGIES can/should/would be deprecated or placed in legacy status, but we are talking about old DATA. You can have the best most modern computer in the world, but sometimes you want to work with a 57 Thunderbird. Shouldn’t a modern updated computer be “good enough” to work with old data constructs?

[code]Function MacType(extends f As Folderitem)

if f <> Nil Then

Dim n As New NSFileManagerMBS
Dim e As NSErrorMBS
Dim d As Dictionary

d = n.attributesOfItemAtPath(f, e)

if d.HasKey(NSFileManagerMBS.NSFileHFSTypeCode) then

Dim FileName As String
FileName = f.Name

TypeNum = d.Value(NSFileManagerMBS.NSFileHFSTypeCode)

if TypeNum  = 0 Then
  
  return ""
  
Else
  
  Dim TypeStr As String
  
  Dim Buff As MemoryBlock
  Buff = New MemoryBlock(4)
  Buff.LittleEndian = false
  
  Buff.Int32Value(0) = TypeNum 
  TypeStr = Buff.StringValue(0, 4)
  
  return TypeStr
  
End If

End If

End If

return “”

End Function[/code]