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.
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)
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
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)
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
end
next
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
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.
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.
@All:
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.