Create and open a MessageDialog from a Thread

In more refactoring for threads, I’ve run into a scenario where I need to show a messagedialog. Of course, this results in the nefarious TAUI exception.

Has anyone come up with a way to display a messagedialog from a thread? I’m thinking that the use of xojo.core.timer.CallLater() isn’t going to help here.

Why shouldn’t the CallLater work? Have you tried? I still use the old DelegatingTimer class but check for a thread first:

[code]dim currentThread as Thread = App.CurrentThread
if currentThread = nil then
// the main thread is active - we can simply call MsgBox here
HandleActionDirect
return
end if

'create the timer
me.ShowDialog = new DelegatingTimer
me.ShowDialog.Mode = 1
me.ShowDialog.Period = 100
me.ShowDialog.Action = AddressOf me.HandleAction

theThread = currentThread
theThread.suspend[/code]

I’m feeling dense (or maybe it’s because it’s 04:22 here)…

I use something similar to display my predefined pacifier windows in that manner. However, I’m talking about using the MessageDialog class and even setting the parameters of Message and Explanation cause the TAUI exception. And I stuck creating new pre-defined windows similar to my pacifiers?

I was making it more difficult than I needed to. CallLater works, I just needed to create a “WarnXXXX” sub that did the MessageDialog setup and then call that from the xojo.core.timer.calllater. For example

xojo.Core.Timer.CallLater(0, AddressOf WarnHeaderReadFailed)

Then put the MessageDialog setup and call in that Sub

Dim md As New MessageDialog md.Message = "Unable to read volume header" md.Explanation = "Either the tape is blank or is a non-BRU tape." + EndOfLine + EndOfLine _ + "Please make sure that the proper tape has been loaded." md.Icon = MessageDialog.GraphicCaution Call md.ShowModalWithin(TopWindow)

Hi Tim,

are you working on tape drive project?

how did you read tape directory, winapi functions?

p.s. sorry for off topic

Tim, my solution for retrofits was to make Thread-“safer” versions of most of the major UI items: Windows, pushButton, Label, ListBox, etc. Each item is a drop-in replacement subclass that can be called from within a Thread. I call them “thread-safer” because they are not 100% thread safe, but when used responsibly they do the trick. When I have some free time I plan to put them online…

[quote=404586:@Zoran Dove?er]Hi Tim,

are you working on tape drive project?

how did you read tape directory, winapi functions?

p.s. sorry for off topic[/quote]

Yes - we’re the BRU Guys and we wrote our own tape I/O functions. The tape functions that MS provides in the Windows APIs are too limiting to truly control the tape device as we can on a Unix system, so it was long in coming to get the control layer in place. We’ve been at this since 1985, so we have a trick or three up our sleeves when it comes to tape layer I/O.

Reading the tape’s content is highly dependent on how the tape was created - BRU, tar, cpio, pax, mtf, etc… A tape is not like a disk in that the software must create the container format that is used. Tapes are just a sequential medium and knowing the software’s format definition is how the tape is written and read.

I had started a project that created my own supers for these where any update or access methods were overridden and just fired a timer to run the event without calling out to the control’s default super.

Similar idea to what I’ve done, although I found it to be more complex. My classes shadow all of the properties internally so that changes seem to happen immediately.

This is important because without it, code like this won’t work:

Thread1.Run
   for i as integer = 1 to 100
     progressbar1.value = progressbar1.value + 1
     ... 
     progressbar1.value = progressbar1.value + 1
  next

Also, they use the timer callback only when called from a thread - if not in a thread, then they behave just like the superclass and changes happen immediately.