DropObject Obj.FolderItem resolve Alias

I was under El Capitan and now under Mojave. With Xojo 2019r1.1, in event DropObject, Obj.FolderItem did return me an alias when I drop an alias. Since Xojo 2019r2 it return me the Target of the Alias.
I don’t have any alert when verify the code and the documentation say nothing about that -> I suppose nothing change in the source code (instruction) to enter.

Note : I use DropObject on a ListBow.

What do you want to do ?

Reject the Alias ? Use IsAlias (if obj.FolderItem.isAlias Then Return

No, I want to get the Alias if I drop one. If I do obj.FolderItem.isAlias the answer Is False as I get the Target of the Alias (I dropped an Alias).

Haveyou read there (API 2):

http://documentation.xojo.com/api/files/folderitem.html.IsAlias ?

[code]Notes

In most cases, a FolderItem is going to resolve the alias to point to the actual file. If you need the actual alias itself, then you should use FolderItem.TrueItem, FolderItem.TrueChild or GetTrueFolderItem.
Example
Var f As New FolderItem
If f.IsAlias Then
MessageBox(“The FolderItem is an alias.”)
Else
MessageBox(“The FolderItem is not an alias.”)
End If[/code]

And due to all I read about 2019r2 and drag and drop (ListBox as an example), I suggest you use the window’s DropObject to check your code, then copy/paste it into the ListBox DropObject.

You mean window’s DropObject in the documentation ? No exemple there.
I opened ListBoxDragAndDrop.xojo_binary_project from the exemple folder of Xojo and I replaced Me.AddRow(obj.FolderItem.Name) by Me.AddRow(obj.FolderItem.NativePath) and I get the Target when I drop an Alias.

No.

I mean to try to put YOUR code there, then if it works, put it back into the ListBox.

The Alias is resolved when you do that.

Try the advice (as you intend to use the droped Alias) and come back. if you have troubles.

I come back with… what do you want to do with the alias file? Dissect it ?

In API 1 I would say you can do that as is since you have to use TrueItem (TrueChild) to get the pointed Object), but with API 2, people have to explorate. But first, people have to know what to do with the Alias.

Did you try to get the Alias .Name and .Parent(s) ?

PS: I have so many troubles with 19r2 than I trashed it. Minutes ago, I downloaded another copy from a faster internet hotspot to check if this was the download or really 19r2 who is bad.

Personally I feel that Xojo shouldn’t auto resolve symbolic links / shortcuts / Aliases. Instead there should be a function folderitem.resolveAlias. I’ve recently been having some complications with these too.

However I realize that Xojo probably isn’t going to change this as it would break a lot of exiating code.

?
In the absolute, yes, but I never had to deal with an Alias, only to the object (item) it points to.

1 break more or or 1 break less does not change many things… they already broke so many things with API 2.

After making some tests, I think it is not possible to red an alias contents (from native Xojo).

Even QuickLook is not able to display its contents (after adding .txt to its ends).

Now, with Declares… maybe (I do not tried with API 1).

PS:
.Name and .Parent returns the original not the Alias. (API 2)
BinaryStream does nothing too (read the original).

On this page http://documentation.xojo.com/api/files/folderitem.html , they write “IgnoreAlias” but anything how to use it.

I have a application which manage files (to rename, change modification date and so on). I have a checkbox to use alias instead of target. With 2019r11 it works great, I want it to work with 2019r2 .

I don’t saw it ! Sorry.

IgnoreAlias is burned far inside the text. Sorry, I do not read the text when searching and instruction; that is what the top of the page rectangles are for.

I cannot help, I trashed 19r2.

The link below does not exists (or do not have the correct case)
http://documentation.xojo.com/api/files/folderitem.html.IgnoreAlias

Search of the docs page returns only FolderItem.

Does it auto complete in the IDE ?

If you have a license for 19r2, ask directly Xojo… and prey.

I tried in the event DropObject of a window and it’s the same problem, the alias is resolve, I get the Target of the alias, not the alias itself.
I filled a BugReport.

Searching in the docs, I found:

http://documentation.xojo.com/api/files/folderitem.html.ChildAt

It have a parameter to deal with the Alias or the target (original file).

Maybe ?

FolderItem.Child(Index as Integer, followAlias as Boolean = true) As FolderItem

[quote=459220:@Sam Rowlands]Personally I feel that Xojo shouldn’t auto resolve symbolic links / shortcuts / Aliases. Instead there should be a function folderitem.resolveAlias. I’ve recently been having some complications with these too.

However I realize that Xojo probably isn’t going to change this as it would break a lot of exiating code.[/quote]
One could do the resolve himself/herself:

Function ResolveAlias(Extends TheItem As FolderItem) As FolderItem
if TheItem=nil then return nil
if TheItem.parent=nil then return TheItem //Without parent, it’s never an alias

Return TheItem.Parent.TrueChild(TheItem.Name)
End Function

(written from scratch, not in the IDE)

I think resolving aliases only when you want it would be really more comfortable, instead of guessing whether any particular function/parameter does it, regardless of how it would break the code (after all, they have decided, with API 2.0, to have all indexes starting at 0; why not using the never-resolve-aliases-unless-explicitly-wanted way as well?).

Thomas want just the opposite: not resolving the alias, but working with the alias file itself.

API 2 apparently resolve the aliases by default. Founding (except my previous answer ?) how to not resolve the alias was the question :wink: