API 1.0 and API 2.0 folder item issues

General
#1

I have a customer who is having a problem once the Ohanaware App Kit is added to their API 2.0 project. Xojo complains that their folderitem constructors (which are API 2.0) are invalid, which were fine before.

Type "Folderitem" has no member named "PathModes"
f = new folderitem( thePath, folderitem.pathmodes.native )
Type "int32" has no member named "Native"
f = new folderitem( thePath, folderitem.pathmodes.native )

The weird thing is I can enter either API 2.0 or API 1.0 into a API 2.0 (with the App Kit present) and get no such errors.

Dim f as new folderItem( "/Users/rowlands/Desktop/test.txt", folderItem.pathModes.native )
f = new folderItem( "/Users/rowlands/Desktop/test.txt", folderItem.pathTypeNative )

Is there any advice I can forward onto the customer as I really don’t know what to suggest? At this point I also cannot convert the App Kit to API 2.0 only as I and some of my customers use it with pre 2019r2 versions.

#2

You could wrap the new calls in

#if XojoVersion >= 2019.02
    // api 2 code
#else
    // api 1 code
#endif

That’s what was done in the IDE.

#3

Understood, any thoughts on the issue the customer is experiencing, whereby Xojo doesn’t like their API 2.0 folderitem constructors after adding the Ohanaware App Kit?

#4

I’m following this thread with interest, as I am the customer. Sam is, of course, the model of discretion . :slight_smile:

Right now I’m using 2020r2.1 but this behavior goes back prior to 2020r1, when I first purchased OAK. Incidentally, if I do “fix” my folderitems, stuff works.

Before I contemplate such a thing, is there any point in tossing out plugins till I see a change? After all, something seems to be making “me” special. :slight_smile:

#5

What’s the type of the thePath variable?

#6

Not in front of the project at the moment, but ‘thePath’ should be a string.

#7

I understand, but make sure it’s not a Text because you may be getting the Xojo.IO.Folderitem constructor instead.

#8

Thanks, Greg. Back at my computer, I can confirm it’s a string.

Another interesting side effect: with OAK in a test project, I do not even get autocompletion if I attempt to construct a folderitem the API 2.0 way.

#9

@Sam_Rowlands
Your kit doesn’t define something called PathModes, right?

#10

It does not…

Screen Shot 2020-12-08 at 9.46.30 AM
Screen Shot 2020-12-08 at 9.46.30 AM956×160 24.2 KB

I wonder, what if there’s a conflict with a plug-in? Would there be any way to detect this?

#11

Hovering your cursor over PathModes in the code editor should show you its parentage in the hint area.

#12

Hovering your cursor over PathModes in the code editor should show you its parentage in the hint area.

I get this:

OAK2020.folderitem(extends w as window, assigns value as folderitem)

Note that I have to hover over the folderitem super instead of PathModes.

#13

Future Jerry: As a hack, I deleted OAK2020.folderitem. Analyzing the project only found a handful of lines in OAK that depended on it, which I commented out.

With this, my test project, which thankfully didn’t need any of that stuff, worked fine.

Note: While the plugins-conflict question appears to have been ruled out, earlier I had temporarily reinstalled a clean 2020r1. This made no difference.

#14

hmmm…

This attaches the folderitem to the window, for use by Resume and to provide a proxy icon (which Big Sur hides)…

I’ll think what to do about it.

#15

You could rename it titleBarFolderItem or file a ticket with Xojo because I think the compiler is actually broken here. Why in the world would it be looking for the PathModes enum on an extends method?

2 Likes
#16

Norman explained to me how the compiler might end up looking at your Extends rather than FolderItem. :grimacing: tough situation, you’ll want to do the rename for sure.

#17

I did this and it worked. :slight_smile:

#18

I don’t want to rename it :slight_smile: lol… However I have done so, for the next release.

I also awoke this morn and realized why I was unable to reproduce it earlier.