Version 2019 r3

How is it that I get 185 errors if I try and compile in 2019 r3 and my app that compile fine in 2019 r1.1?

I thought backward compatibility was a key goal of software developers, especially for apps such as Xojo.

If there is such a difference, wouldn’t Xojo want to create a tool to help people move to the new version.

I have thousands of lines of code that will now not compile.

Has anyone developed a document that shows a path to upgrade one’s source.

I really think this is a horrible way to treat your customers. I don’t ever remember Microsoft doing anything like this?

Xojo, any response?

Can you list some of the errors?

Here one, alot of these:
frmEOM.ProcessVPM, line 53
Type “FolderItem” has no member named “AbsolutePath”
lfiCompleteFinalNoticeListFileName = GetFolderItem(gfiEOMPath.AbsolutePath + lsFileName)

mdGlobals.CheckDate Declaration
Can’t find a type with this name
Function CheckDate(lsDate as DatabaseCursorField) As String

mdGlobals.CheckDate, line 4
This item does not exist
Return lsDate.DateValue.ShortDate

I saw someone say something about there will be a tone of Database errors too.
The compiler just can’t get to that with all these.

FolderItem.AbsolutePath was deprecated in 2013r1 and removed in 2019r2.

DatabaseCursorField is so old I have no idea when it was deprecated, but I’d guess over 10 years ago and I believe was also finally removed in 2019r2. DatabaseField or the newer DatabaseColumn would be your options.

Some things that might be worth reviewing:

AbsolutePath was REMOVED from folderitem
you’ll want to swap that for something else (more than likely NativePath BUT be warned there are differences in how that is represented from the old AbsolutePath)
OR adopt one of several extnsion method (I think Jurg posted some) that make absolutePath work again (but still I’d say you want to start migrating away from it as that too may one day break)

DatabaseCursorField was similarly removed (finally)

What are the differences between AbsolutePath and NativePath. What differences?

I take it it’s not as simple as a global replace?

What about to recordsets, hav that changed as well?

On macOS a lot; on WIndows nothing afaict
On macOS absolute path used the old : as a separator
Native path is a unix style path with / separators

so you have to watch out for that
and they are rooted differently in the file system
so while an old absolutepath might have said “Macintosh HD:username:blah blah” a native path might be “/Users/npalardy/blah blah”
so careful there

recordsets havent changed (but were / are deprecated) - but they still work as is
databasecursorfield you should be able to replace with DatabaseField

FWIW this is why Xojo publishes release notes in each release in the Documentation dir, under the New in this release menu items and online

OK Here some code the way it was originally written:

The Temp folder is located under the folder that the app is in.

lfiTemp = GetFolderItem("Temp")
if not lfiTemp.Exists then

gfiEOMPath = lfiTemp

Then later it is used:

lsFileName = CleanFileName(lsChapter) + "-Roster"
lsFileName =lsFileName + ".csv"

lfiCompleteChapRosterFileName = GetFolderItem(gfiEOMPath.AbsolutePath + lsFileName)

So can I replace AbsolutePath with NativePath and I’m done?

90% of the errors are like:

frmEOM.ProcessChapter, line 15
Type “FolderItem” has no member named “AbsolutePath”
lfiCompleteChapRosterFileName = GetFolderItem(gfiEOMPath.AbsolutePath + lsFileName)

Since you already have a FolderItem, you should not use GetFolderItem. You should build from it instead. This might be a more correct conversion:

lfiCompleteChapRosterFileName = gfiEOMPath.Child(lsFileName)

If I’m reading the code correctly, it looks like you’re trying to create a file inside gfiEOMPath.

Yea it holds the Temp folder name, a sub folder of the applications folder.

Later I’m doing this:

Dim lsTempFileName() As String
lsTempFileName.Append  lfiCompleteChapRosterFileName.AbsolutePath
lsTempFileName.Append  lfiCompleteNewPendChapRosterFileName.AbsolutePath
lsTempFileName.Append  lfiCompleteUnLocatableListFileName.AbsolutePath
lsTempFileName.Append  lfiCompleteUpdateListFileName.AbsolutePath
lsTempFileName.Append  lfiCompleteFinalNoticeListFileName.AbsolutePath
lsTempFileName.Append  lsCompleteRevokeListFileName.AbsolutePath
lsTempFileName.Append mfiMembershipStandings.AbsolutePath

So what would I do here?

swap that for nativepath ?

hard to be sure since I cannot tell what you do with lsTempFileName later on

It is attaching files to an email:

Mail.Append(  GetEmailMessage(lsEmail, lsTempFileName, lsSubJect + " Region " + lsRegionChair, lsConfirmationEmail))

The lsTempFileName is lsFile()

Dim lnCnt as Integer

'dim file as eCurrentEMailAttachment
Dim lfiFileToAttach as FolderItem
for lnCnt = 0 to UBound(lsFile)
  lfiFileToAttach = GetFolderItem(lsFile(lnCnt))
  if lfiFileToAttach.Exists then
      CurrentEMail.AddAttachment( lfiFileToAttach,"", "") ' Attachments.Append file

The most broad advice I can give is to stop using paths entirely. Use FolderItem instead. Use paths only when you need to get data in or out of your app, such as saving to a preferences file. Even then, there are better options such as save info and security scoped bookmarks.

In the second example, lsFile should be an array of FolderItem. So you’d do

For Each lfiFileToArrach As FolderItem In lsFile If lfiFileToAttach.Exists Then CurrentEMail.AddAttachment(lfiFileToAttach, "", "") End If Next

Except AddAttachment takes a string not a folder item.

CurrentEMail is CurlEmailMBS

So that wouldn’t work

In that case, my advice would be to use lfiFileToAttach.NativePath as that is an instance of pushing data outside your app.

The trouble is AbsolutePath and NativePath are not compatible. So nobody feels comfortable telling you to just exchange AbsolutePath for NativePath. FolderItem has a lot of advantages over using paths, so that’s a better directly to go in.

Yeah, and according to the docs that string is data not a path. You should pass it a FolderItem.

There is a piece of information that was not sai here.

Beside the deprecated / removals pages, the Release Notes, etc., there is something you can do while developing and probably before upgrading:

in the code editor, you have six buttons (the left one allows to add Events, Handlers, Methods, Notes, etc.), another allows to set / remove line numbers.

The last on the right is Analyze.

This … Analyze your code and returns a list (eventually) of information like deprecation.

@Richard: load that project in 2019 r1.1 and do that. You will get there most of the errors you already saw.

It may be a good idea to do that before releasing your product, before upgrading to a new Xojo version.
Reading the Deprecation/Removals document is also a good idea (and the Release Notes too).
Of course, this also is a question of memory.

If you still need AbsolutePath for compatibility, we still have it in MBS Plugins.

Guys thanks, I will attack this tomorrow and sunday, so I’m sure I will have more questions.

So in using absolutePath in the above example, isn’t there a way I can pull the path to the files in string from NativePath?

As was mentioned above you don’t need to use AbsolutePath or NativePaths because you already have Folderitems.