QProgressDialog - QTcontribs examples

[Zoran Sibinovic]

Hi,

I tried to find some example of Qprogressdialog use in qtcontribs but with no luck.

Also looked at the qt-project.org class reference and tried to make some simple dialog.

As a simple dialog I choose to make a busy dialog and its ok, but only to be displayed 

********************
FUNCTION Waita()

LOCAL oPD

oPD:=QProgressDialog()
oPD:setWindowTitle("Wait...")
oPD:autoReset()
oPD:setRange(0,0)
   
oPd:exec()

but haven't achieved two things

1. where to write the process code to be executed during the lifetime of this dialog, some copy, replace open or else 

2. how to exit from it when MyProces() ends 

The dialog must have no dependency of the main app so can be called from any app window/dialog like alert() and modal to the latest opened window.

To make it easier, the percent of the process doesn't matter, just a busy look.

Thanks for some example

Zoran 

[Francesco Perillo]

Just reading Qt docs... you don't have to call :exec() otherwise you give control to the loop an dprogram doesn't continue.

You must know how many steps you need to do for completing your job, imagine there are 365 steps.

oPD:setRange(1, 365)

for i := 1 to 365

  oPD:setValue( i )

  IF ( oPD:wasCanceled() )

     exit

  ENDIF

  ProcessDay( i )  // do what you need to do..

next

Now it should work... probably :-)

Zoran 

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.
To post to this group, send email to qtcon...@googlegroups.com.
Visit this group at http://groups.google.com/group/qtcontribs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Luigi Ferraris]

Il 17/04/2013 14.05, Zoran Sibinovic ha scritto:
> Hi,
>
> I tried to find some example of Qprogressdialog use in qtcontribs but
> with no luck.
>

Hi Zoran
a very simple usage

STATIC PROCEDURE Waita()

LOCAL nSecondsToWait := 10
LOCAL nSecondsElapsed := 0
LOCAL oPD

WITH OBJECT oPD:= QProgressDialog()
:setWindowTitle(....)
:setWindowIcon( ....)
:setLabelText(...)
:setMaximum( nSecondsToWait )
:setWindowModality( Qt_ApplicationModal )
.... see Qt docs for other
END WITH

oPd:show()

WHILE nSecondsElapsed <= nSecondsToWait
IF oPd:wasCanceled()
... user press cancel
oPd:setValue( nSecondsToWait ) <<--- I suggest to you using it
ELSE
INKEY( 1 )
nSecondsElapsed += 1
oPd:setValue( nSecondsElapsed ) <<- to upgrade bar
ENDIF
END

RETURN


As I write isa a very sample. Instead nSecondsToWait you can use
<cAlias>->(LASTREC()) and nSecondsElapsed....
About parent or not... you can use QProgressDialog( oWindowParent )
About setWindowModality....to block any other use interaction

Cheers

Luigi Ferraris

[Zoran Sibinovic]

Hi,

Thanks both,

  

I have read the qt doc, just always found some example, not for our QTcontribs, with some timer or percent of processed process to control the slider.

I needed only to construct a busy indicator, think is simpler.

I will surely study yours code.

Thanks again 

Zoran

[Zoran Sibinovic]

Hi,

after tried the examples I can conclude that in mine example the busy bar works with :exec, but i can't do anything in it because the loop, except maybe by start in it a new thread for MyFunc() and connect to ...something. On the other hand, by calling :show() the progress bar cannot update automatically even I :setrange(0,0) and :autoreset() because it waits to be manually updated.

   

In both examples the bar movement depends of calling :setvalue() from time to time somewhere in MyFunc(), but what If we don't know the number of steps that we have (in Francesco's example 365 steps, in Luigi's 10 steps each 1sec. )   

Googling I found some examples of waiting an internet connection to be established by using a :connect() line or a timer use, but in some other languages.

So, It is possible to construct an indeterminate Qprogressdialog that works independently of the Myfunc() ?  Myfunc than, when finished will return some signal to the Qprogressdialog to ends, or something like this:

...some app code

...

oPb:=Qprogdial() /// start an indeterminate dialog

....

...

Qprogdial(oPb)  /// ends the dialog

...

or maybe, it cannot be done how I imagine it. 

Thanks

Zoran

   

[Francesco Perillo]

Can't understand your message fully.

QProgressDialog MUST be updated manually with :setValue().... If you don't  know the number of steps, you can use a timer to update the values.

Each second increase the value.

Zoran

   

[Zoran Sibinovic]

Hi Francesco,

i will try to make me understandable.

... some code

...

then by clicking some pushbutton, the event starts some function() that start the display of a indeterminate progressdialog and, at the same time, starts dosomething(). For the duration of dosomething() the progressbar works and updates automatically, not from a dosomething() :setvalue() and when dosomething() finishes, the progressdialog finishes too. The goal is to update the progressdialog by itself during a dosamting.

...

IF ISPUSHEDBUTTON()

   displayindeterminateprogressdialog() /// something 

   ...dosomething.... ///without included calls to to the progressdialog like :setvalue()

    enddisplayindeterminateprogressdialog() /// :cancel()   the progresdialog

ENDIF 

Is this possible to achieve?

Zoran

[Zoran Sibinovic]

... continue to the previous, maybe better

Is it possible to start some dialog with :exec(), to work a a standalone thread, at the same time return the control to the main window to do something and close then the dialog when it finishes the work?

Zoran

[Francesco Perillo]

No, as far as I know, there is no way to have QProgressDialog to auto-update, as per Qt docs.

I suggest you to create a modal dialog, show it on screen with :show(). In the dialog put a button, a QProgressBar set to indefinite and if you want to be able to interrupt the job, a button.

There is a sample in Qt Assistant.

QProgressBar will allow you to have an indefinite progress bar.

Zoran

--

[Zoran Sibinovic]

Hi,

I achieved this as a wait window:

.....

Local owaita

owaita:=WAITA()

...  //

...  // some long process

...  //

owaita close()

********************

FUNCTION Waita()

Local oLb,pIxy
oLb:=QLabel()
oLb:setWindowTitle("Information")
pIxy:=QPixmap("waitharbour.png")
oLb:setPixmap(pIxy)
oLb:setMask(pIxy:mask())

oLb:show()

oLb:Move((desktop:width()-oLb:width())/2, (desktop:height()-oLb:height())/2)
olb:repaint()

RETURN oLb

why I chose a picture instead a progress bar?

I've made lot of experiments, the most closest is to make a Qdialog, build inside a progressbar and :show() it, as Francesco said.

What's happens:

the dialog is shown, but the progressbar not.

After lot of googling the problem is explained in "Keeping the GUI Responsive" article 

http://www.qtcentre.org/wiki/index.php?title=Keeping_the_GUI_Responsive

I don't know if QTcontribs supports the creations of threads by ex. Qfuture or else so i choose this kind of wait dialog for now.

It don't have even to make the label or dialog to be modal, because you cannot do anything before the processed code after :show() finishes, only waiting the:close() event.

Zoran

 

[Pritpal Bedi]

Zoran 

I achieved this as a wait window:

Question is:

Do you want a progress bar behaves as MODAL or MODELESS.

In MODAL scenario no GUI component is accessible for the duration the underlying process is running, progressbar is simply updating the progress.

In MODELESS scenario, progressbar is a part of a process, and updating, but you can do the other things also.

So progessbar can be displayed in a multiple of ways depending upon the need of appln.

Pritpal Bedi 

[Zoran Sibinovic]

Hi Pritpal,

I want this:

MAINWINDOW()
...
by pushing some button or choosing a menu item to start some MYWINDPROGBAR() function
...
... // long process event (we don't know when it will ends)
...
:close() - the window progress bar
display a "Finished" message

MYWINDPROGBAR()
have to not allow the user actions on mainwindow
display an indefinite progressbar like the gif in the attachment - :setrange(0,0)
and make it works till the :close() event
RETURN

I can only hope that is possible to achieve this.

Zoran

[Dušan D. Majkić]

> // long process event (we don't know when it will ends)

This depends on the long process in question.

The issue is that (almost) all GUI drawing, mouse tracking system
events, timers, and everything else including your code - is executed
in one WHILE TRUE DO loop. It is in Application():exec().

If you put some long running blocking code, like inifinite loop, then
your whole app will block. That is the way GUI works.

If your event is some kinde of loop, than you can put some code inside
that updates GUI, or check if event was aborted. For example if you
have FOR - NEXT, you can put your check right before NEXT.

If the "long process event" is system blociking, (like network dns
lookup, or filesystem wait), than there is no other way but ot use
threads. And it would be a better idea to put that "long event# code
in the thread, and display wait window in main thread. Also consider
that threads bring another level of complexity to code, are harder to
debug, etc..

Regards,
Dusan Majkic
Wings software

[Zoran Sibinovic]

Hi dmajkic,

that's ok, I can try with a thread, but, with a use of hb_threadStart() or some Qt thread class ?

I haven't found some in QTContribs

Zoran

[Francesco Perillo]

hb_threadStart()

remember one important thing: only the main thread can update the screen... in a few words and to simply a lot: in the detached thread do only harbour/dbf/network stuff and don't use hbQt objects.

--

[Zoran Sibinovic]

Thanks Francesco

[Luigi Ferraris]

Il 18/04/2013 23.43, Zoran Sibinovic ha scritto:
> Hi dmajkic,
>
> that's ok, I can try with a thread, but, with a use of
> hb_threadStart() or some Qt thread class ?
>
> I haven't found some in QTContribs
>

Hi Zoran.
IMHO, if you are started to use hbqt, in other words Qt, I suggest to
you to stay away from multi thread because if is the "first time" you
use Qt you have a lot to read, understand.
First of all remember that you will work with GUI as Dusan remember to you.

Prorbaly, you need to configure your QProgressdialog to wait an infinite
loop, btu you must "customize" your object.
ie:
QProgessDialog:setMinimumDuration( 0 )
oQtProgressBar := QProgressBar( <progressDialog as parent> )
oQtProgressBar:setRange( 0, 0 )
oQtProgressBar:setValue( 0 )
QProgressDialog:setBar( oQtProgressBar )

.... and know you need a QTimer object to be connected to update progressBar

With your customized object you can use this code

LOCAL oMyCustomizedObject

oMyCustomizedObject:show()

WHILE .T.

QApplication:processEvents() // most important to avoid GUI freezing
IF oMyCustomizedObject:wasCancelled()
EXIT
ELSE
Do something code
ENDIF
END
.....

So what I want say to you, as Pritpal and Francesco write, Qt is very
"complex" and it has a lot of "properties", usage and related manging.
When I start to use hbqt, in other words Qt, I follow many examples on
internet and I replicate them with hbqt.....
This link can be one to read
http://www.qtcentre.org/archive/index.php/t-45782.html?s=4c07902b64dca4173572b22a9bba127a
I think it's very difficult to have all the examples (or solutions)
within hbqt/qtcontribs folders

@Pritpal what is the right project "name / reference" ? :)

Luigi Ferraris

[Zoran Sibinovic]

Hi Luigi

thanks for the replay

I will reconsider if it is worth to do lot of experiments only to provide the user the information that the app works and not stuck.

Zoran 

[Pritpal Bedi]

Hi

@Pritpal what is the right project "name / reference" ? :)

I could not understand you...

Pritpal Bedi 

[Luigi Ferraris]

I'm sorry.... when we write or when we speak about this big project, we must use "hbqt" or "qtcontribs". Is a stupid question...

Luigi Ferraris

[Pritpal Bedi]

Hi Luigi

I'm sorry.... when we write or when we speak about this big project, we must use "hbqt" or "qtcontribs". Is a stupid question...

Rather intelligent question !

When we speak of build system and composit Qt related development, 

address that with QtContribs.

When we speak of individual components, then we address them by proprietory 

notation, e.g., HbQt, HbIDE, HbDBU, HbXBP, HbQtWidgets, etc.

Pritpal Bedi