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.
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 windows DropObject to check your code, then copy/paste it into the ListBox DropObject.
You mean windows 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.
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 shouldnt auto resolve symbolic links / shortcuts / Aliases. Instead there should be a function folderitem.resolveAlias. Ive recently been having some complications with these too.
However I realize that Xojo probably isnt going to change this as it would break a lot of exiating code.
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 .
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 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.
[quote=459220:@Sam Rowlands]Personally I feel that Xojo shouldnt auto resolve symbolic links / shortcuts / Aliases. Instead there should be a function folderitem.resolveAlias. Ive recently been having some complications with these too.
However I realize that Xojo probably isnt 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?).