Hi there,
a question here for xojo pros:
how can i search through a folder + subfolders and find all files *.ini for example :)?
Hi there,
a question here for xojo pros:
how can i search through a folder + subfolders and find all files *.ini for example :)?
The system is usually much faster than anything based on Xojo.
Mac ? Windows ? Linux ?
AndÂ… what do you want to do with the results ?
You have to write code to let the user choose the master folder, then write a recursive method who will store the .ini files somewhere / in some container.
dir /b/s *.ini
read some information from this files. I dont want to use some systemcommands in case it should run on any system or?
If you have to search through a lot of folders and subfolders you will need to code for each system, using shell or declares, as that is going to be faster by miles than using Xojo folderitems and recursive searching. What systems do you mean? The Mac shell command ( find ) will be the same as that on Linux, so you really have to worry about two - Win and Mac/Linux.
Peter is right.
If you search in this forum, you may found code to do that faster, but I forget what/ where / when.
dunno… get a output like this in a listbox seems to be complicated…
Well as it’s been said, if you have a large selection of files to sort through you will want to use system specific declares because they will be far faster for your end user.
If it’s a small sample of files, the code to list the files in a folder is actually in the documentation for FolderItem
, and you can adapt it to only display certain files.
Not really. Have a look at the example: FileBrowser.xojo_binary_project
in the example folder.
Reading about 800 folder names (only) and placing these names into a Listbox (AddRow) / FolderItem reference in RowTag is awfully slow on Windows (5 seconds or soÂ…), less than a second on OS XÂ… (by experience). Just 800 files in a single folder.
Dunno in VisualStudio things like this works rly fast o.O
But not, unfortunately, on a Mac.
“any system”? INI files are a WINDOWS concept, and one that was deprecated years ago… what other systems might you consider you might need this feature for?
Sry this is a myth…actual game engines like unreal4 using inis on all systems
and every good windows programmer knows not to use the registry
well from an official point of view , it is fact… INI concept IS deprecated…
the fact the others still use it was part of my question…
as a matter of fact I have an “INI-like” class for XOJO [note : I said “like”… ]
of course, but then if you DON’t use the registry… Microsoft doesn’t consider you a “good programmer”, their rules, not mine.
It is never wise to trust Microsoft too blindly.
I guess that flagged answer is the OP’s way of saying never mind.
Anyway, I would try to use system commands (or MBS’s FileListMBS) because that’s a lot faster than using FolderItems.
If you need/want to use FolderItems, then a function like this should work:
Function getFilesByExt(fFolder As FolderItem, sExtension As String, Optional bRecursive As Boolean) As FolderItem()
// Returns FolderItem() with items from bRecursive fFolder that have File Extension sExtension
Dim fWrk, fResult(), fRecursive() As FolderItem
Dim sNameParts() As String
If fFolder <> Nil And fFolder.Directory Then
// Use iItems to speed things up
Dim iItems As Integer = fFolder.Count
For i As Integer = 1 To iItems
// Use fTmp to speed things up
fWrk = fFolder.Item(i)
If fWrk.Directory Then
If bRecursive Then
// Go recursive
fRecursive = getFilesByExt(fWrk, sExtension, bRecursive)
Dim iItemsR As Integer = fRecursive.Ubound
For r As Integer = 0 To iItemsR
fResult.Append(fRecursive(r))
Next
End If
Else
// Add to fResult() if Extension matches
sNameParts = Split(fWrk.Name, ".")
If sNameParts.Ubound > 0 And sNameParts.Pop = sExtension Then
fResult.Append(fWrk)
End If
End If
Next
End If
Return fResult()
End Function
It returns an Array of FolderItems that have xyz extension. Use the optional flag to go recursive.
Maybe you can tweak it a bit more to make it go faster.
especially since I was ASKING him a question, not providing an answer
It is never wise to trust Microsoft [at all]