Use this code to complete the same job the error does not occur, why the hell is this?
Function GetDate(ByVal Path, ByVal DateType)
Set FSO = CreateObject("Scripting.FileSystemObject")
If FSO.FileExists(Path) Then
Set Item = FSO.GetFile(Path)
ElseIf FSO.FolderExists(Path) Then
Set Item = FSO.GetFOlder(Path)
GetDate = 0
If IsObject(Item) then
Select Case LCase(DateType)
GetDate = Item.DateLastAccessed
GetDate = Item.DateCreated
GetDate = Item.DateLastModified
Set Item = Nothing
Set FSO = Nothing
Function GetType(ByVal Path)
Path = .GetAbsolutePathName(Path)
Select Case True
Case .FileExists(Path) : GetType = 1
Case .FolderExists(Path) : GetType = 2
Case Else : GetType = 0
Function Is_File(ByVal Path)
Is_File = (GetType(Path) = 1)
Function Is_Folder(ByVal Path)
Is_Folder = (GetType(Path) = 2)
Function Is_Exists(ByVal Path)
Is_Exists = (GetType(Path) <> 0)
Select Case CompareData.Col
If Not CompareData.Item.is_dir Then 'Is_File(CompareData.Item)
If CompareData.Item.Create = CompareData.Item.Modify Then
CompareData.Sort = 2
CompareData.value = Cstr(True)
CompareData.Sort = 1
CompareData.Sort = 0
'If Is_File(CompareData.Item) Then
If Not CompareData.Item.is_dir Then
If CompareData.Item.size = 0 Then CompareData.value = CStr(True)
Select Case LCase(DType)
Case "a" : FileDate = DOpus.FSUtil.GetItem(FilePath).access : GroupText = "访问于 "
Case "c" : FileDate = DOpus.FSUtil.GetItem(FilePath).create : GroupText = "创建于 "
Case "m" : FileDate = DOpus.FSUtil.GetItem(FilePath).modify : GroupText = "修改于 "
I translated above Chinese words for you guys discuss better.
That code I uploaded run corrent in my office computer,but get error in my home PC.The version of Doups in my office is 12.4,home version is 12.3.OS are win10 X64 both.
If the home computer is updated to the latest version, does it work then?
If not, it looks like something that might be caused by something in a particular folder. If you can work out which folder(s) it happens in, and see if there is anything special about them, that should help us work out what is going wrong.
For example, if it only happens when you view the Desktop folder, it might be due to the special This PC item in that folder, if it is turned on.
"C:\Users\qiuqiu\Desktop\OneDrive" is not a real file or folder. It does not exist on disk.
Have a look in "C:\Users\qiuqiu\Desktop" and you will not see a "OneDrive" file or folder. It isn't there.
If you look in your virtual Desktop folder, you may see a OneDrive item in there, which links to a folder somewhere else.
The virtual Desktop folder also shows you the things in "C:\Users\qiuqiu\Desktop".
The virtual Desktop folder also shows you the things in "C:\Users\Public\Desktop".
The virtual Desktop folder is not the same as "C:\Users\qiuqiu\Desktop". They are two different things. The virtual folder does not exist on disk; it combines various folders and items into a view that shows them all at once. Some of things do exist on disk, in different places. If you use the virtual folder in a context that needs a real folder path, it will usually turn into "C:\Users\qiuqiu\Desktop" as that is the best approximation, but the two things are not the same.
If you pass "C:\Users\qiuqiu\Desktop\OneDrive" to FSUtil.GetItem it will fail, because "C:\Users\qiuqiu\Desktop\OneDrive" does not exist. FSUtil.GetItem won't return an object in this case.
If you try to call .access on the result, you'll get an exception, because the result is not an object and has no .access method or property.
Nothing wrong or surprising here. And nothing that would happen in "any folder by pressing F5"; this is all specific to the Desktop virtual folder, at least so far.