Window.Show versy slow on Windows

Hi Windows gurus,

I have the following very simple code in a drop object event on a Canvas:

If obj.FolderItemAvailable Then
  Dim FolderSize As DirectorySizeMBS
  // BuildStandbySheetDialog populates a predefined custom dialog with content
  BuildStandbySheetDialog("Examining Source Volume", "Please stand by while the specified migration source is checked ...", Nil)
  wStandbySheet.ShowWithin(Self)
  wStandbySheet.Refresh
  FolderSize = obj.FolderItem.CalculateDirectorySizeMBS
  EstArchiveSize = FolderSize.PhysicalTotalSize   // LogicalTotalSize
  lSourceSize.Text = kSourceSize_text + SizeFromBytes(Format(EstArchiveSize, "#"))
  wStandbySheet.Close
End If

However, the wStandbySheet window does not appear unit the processing is completed in the following statements - obviating its usefulness …

I’ve also tried moving the ShowWithin to a Timer with the same lack of results.

Does anyone have a magic incantation to get this working as the flow implies?

Xojo 21r3.1 and Xojo 22r1 on Windows 10 and 11.

Hmm. The size calculation code is probably the culprit - it is probably tying up the main thread before it has a chance to make that sheet window show up.

I suggest you move all the code that does the actual work into the window itself, triggered by the Open(ed) event. This will ensure that it only starts once the window is actually visible.

maybe with a to do list.
u use a timer to pick a single task/step.
so the eventloop continue between this steps.
a enumeration could help you.

I’ve now added a Thread to the window and moved the CalculateDirectorySizeMBS call into that - same result. @Christian_Schmitz - are you blocking background events in that function?

The background events are probably blocked. For FileListMBS there is a YieldTicks:

FileListMBS.YieldTicks = 10

1 Like

yes, you have to tell the plugin to yield, since yielding makes it run a bit slower.

The YieldTicks works fine for an intermediate number of folderitems. If I select a super large folder like my copy of the 1.4 million Enron emails then I still get the beachball.

A while ago I did some testing with Instruments and accessing the folderitems was the bottleneck.

1 Like

How about:

Add a timer to the standbysheet
Show the standysheet
Start the timer
launch the GetSize code in a thread
Have the timer check now and then whether the thread is complete, and close when it is ?

…or does the plugin kill the timers too?

Even with a thread there is the beachball.

I imagine Christian could improve this so that if it was called from a Xojo thread it blocked less by using preemptive threads.

It’s also the kind of task that would work better if Xojo had proper threading.

1 Like

Tried this up to 100 ticks with no change. Should this be in in the Thread before Calling CalculateDirectorySizeMBS, or as a global or protected call in the Window’s open?

I have YieldTicks in App.Open.

Are you using a current Xojo? Is this the kind of thing a Worker will be useful for?

I imagine a worker would help in this scenario. However, the fact that a few lines of code have to moved into a separate app to solve this problem highlights a significant limitation in Xojo.

So CalculateDirectorySizeMBS has a ticks parameter.
You can pass a value > 0 to enable yielding, e.g. 3 to yield around 20 times per second.

1 Like

And as I said above the YieldTicks work fine for an intermediate number of files. If I select a million files then I still get the beachball.

I’d love to use a worker to speed up loading the files.

I’ll give that a shot this afternoon and report back.

@Christian_Schmitz - is this new to MBS 22r1? I’m using 22r0 and I get:

wMain.cvDropSource.MouseDown, line 68
Parameter "recursive" expects type Boolean, but this is type Int64.
FolderSize = f.CalculateDirectorySizeMBS(3)

Please read the documentation on the parameters:

CalculateDirectorySizeMBS(recursive as boolean = false, ticks as Integer = 0, QueryCompressedSizes as boolean = false, RecursionLimit as Integer = -1)

So first is boolean of recursion, then integer for ticks.

Not only did that (True, 3) allow the dialog to appear, but it also makes the calculation task complete recognizably faster - even on a 122TB folder hierarchy, the pacifier dialog wasn’t even necessary.

Without those parameters, the 122TB folder caused the beach ball to appear and stall the UI for over 18 seconds. With the parameters of True and 3, it finishes in less time than it takes my Pacifier dialog to appear and be visible - sub 2 seconds by simple counting.

macOS and Linux were the test platforms.