Threading...

Hi Mark,

I have to disappoint you. Threading is not supported in the ABL.

The fact that the BackgroundWorker is available in the toolbox is a bug.

It does not work.

-peter

Ah, I see.

That's a shame.

Thanks for the help

We had a simlar discussion just recently: http://communities.progress.com/pcom/message/55584#55584

(And there's a link to another thread as well).

If the client is actualy busy - and not just waiting for a single long running DB operation or appserver call to finish - you can use an animated GIF in a PictureBox control. A PROCESS EVENTS or call to the :Refresh() method of the picturebox will update the image. Depending on the nature of the processing that's something you may do every n iterations of a loop or so.

The official term from the 10.2A EULA is that the use of threads is prohibited - and not just unsupported.

Once again, thanks to every body for your help!

You might want to also talk to your salesrep about how much you really want multithreading.

http://www.oehive.org/MultiThread

It's not trivial, but it is time to cross this bridge.

You can try hijacking the System.Timers.Timer which fires its Elapsed event in separate Thread. With what I know about .NET programming, application has a defualt ThreadPool even in a single threaded application. I'm not exactly sure if this was overlooked because it works somewhat. NOTE: You can not use a class level variable to to cancel the loop. ABL can not communicate variable changes on time to the Elapsed thread. The UI remains responsive while the loop is being processed just don't try to update any variables that are being used by the Elapsed event outside the event handler.

DEFINE PRIVATE VARIABLE timer AS System.Timers.Timer NO-UNDO.

timer = NEW System.Timers.Timer(100).

timer:Elapsed:SUBSCRIBE(timer_Elapsed).

timer:Enabled = TRUE.

METHOD PRIVATE VOID timer_Elapsed(INPUT source AS System.Object, INPUT e AS System.Timers.ElapsedEventArgs ):

DEFINE PRIVATE VARIABLE cntr AS INTEGER NO-UNDO.

DEFINE PRIVATE VARIABLE percent AS INTEGER NO-UNDO.

IF NOT isScanning THEN

DO:

isScanning = TRUE.

timer:Enabled = FALSE.

DO cntr = 0 TO 1000000:

percent = (cntr * 100)/ 1000000.

/* let's not spam the UI */

IF cntr MODULO 500 = 0 THEN

DO:

label1:Text = STRING(percent) + " : " + STRING(cntr).

END.

END.

isScanning = FALSE.

END.

END METHOD.

Normally the line with label1:Text is a cross-threading update violation.

I guess doing some "long running processing" withing the Timer's Elapsed event handler does not solve the orignal posters question:

I wish to open a "progress bar" dialog box from a window while performing a potentially lengthy operation.

You can at least use the Form's Timer to spin the progress bar in some interval, and use ONE elapsed event of the System Timer to do the long running process without losing UI responsiveness.

Did you try that out? If so, please post a running piece of code.

I just tried it and while in the Elapsed event of the System.Timers.Timer (doing the long processing) the whole UI is frozen, causing that I can't move the Form and the Elapsed evnet of the SWF Timer does not fire.

Hmmm, System and Form Timers don't want to play nicely. Just having the System timer won't lose the UI responsiveness, but having the Form Timer also anabled at the same time locks the UI.

Yes, the progress bar update needs to be inside the Elapsed time. Also, my comment is not about using System.Timers.Timer for processing in an interval, it's about using the timer pulse as pseudo-thread because it is a separate thread by the timer's implementation. Whatever/whereever that thread is running I don't know if the ABL is really enforcing a single-thread affinity.

It's not the two different timers that don't play nicely together. It's the AVM (Progress Virtual Machine) and multithreading that don't play together at all.

It's correct, that you can use (it's a different question if that's already violating the license agreement for OE10.2A, see below) the System.Timers.Timer and that might be living in it's own thread. But as soon as an ABL event handler (that's where your long running processing is happening) is executed this happens in the single threaded AVM. Good old unmanaged C code. ABL code is not executed in the CLR. The AVM hosts the CLR.

It's true that the UI seems to be responding (you can move around the window and you don't have repaint issues) - because that happens in the CLR.

But as soon as an event (let's say an button click or the event of the SWF timer) somewhere else executes and ABL event handler, this has to wait until the AVM is idle again, so when the long running event handler for the System.Timers.Timer:Elapsed event is finished.

So the user can move around the window, minimize and maximize it (as long a he has no ABL window-resized handler) - but for my understanding multithreading would enable us run two or more long running processes simultaneously and the UI would still be responsiveness. The AVM simply can't handle that!

"At this time, the allowable uses of the Bridge are restricted to developing or deploying Microsoft .NET Winforms User Interfaces for business applications using OpenEdge products, and for one-way usage of AVM calling the CLR (and not vice versa).   

Any use of the Bridge other than as set forth in the previous paragraph is prohibited.  Additionally, the Bridge may not be used for multi-threaded processes."

I'm with you that it would be nice to have a multi threaded client some time soon (other things are higher on my personal priorities list). But I think for anybody using the GUI for .NET today it's important to know it's limits.

On my priority list, it is a *lot* higher than "nice to have" ... and not because of UI, although it would be good there too, but for writing services.