Using IProgressMon for my custom IOperation SOLVED

[zarkogajic]

Hi Support,

How would I go about displaying the standard progress monitor for my IOperation being done in the background (AsyncDo...)?

I've tried with

Code: Select all

//pseudo code
MyIOperation.Do
{
	IProgressMon iProgress = Inst.DefaultProgressMon;
	iProgress.Duration = 100;

	ALSO TRIED:

	IProgressMon iProgress = InstAUX.CreateStdRangeProgressMon(Inst.DefaultProgressMon, 100)

	iProgress.Start
	
	while Pos < 100
	{
		//do something...
		
		iProgress.Pos += 1
	}
	iProgress. Stop
}

No errors, but the progress dialog does not come up...


-žarko

[Sasha - Tracker Dev Team]

Hello zarkogajic,

For starters, as you have mentioned, the progress should be used, when the operation is called via the Async method.
The procedure should be as followed:
1) Obtain the progress monitor via the IPXV_Inst::ProgressMon
2) Set you title, style and text. Also, put a duration for your progress.
3) Call a Start method
4) For each needed iteration, you should change the position of the progress and also text if needed
5) Call a Stop method

Note, that if the operation is very fast, then the progress won't show itself as it has a small timer to appear.

Cheers,
Alex

[zarkogajic]

Hi Alex,

Thanks.

Note, that if the operation is very fast, then the progress won't show itself as it has a small timer to appear

That was it - too fast

Can I alter the timer so it starts earlier?

Btw, say I execute multiple IOperations using AsyncDo and each uses a progress dialog: Inst.ProgressMon. Inst.ProgressMon is singleton, right? Seems I would need to go with CreateStdRangeProgressMon (?) as each operation being executed at the same time will have different values (duration, pos text, ...)


-žarko

[zarkogajic]

Hi Alex,

So, yes Inst.ProgressMon is a singleton - therefore cannot use it when having multiple IOperations running at the same time (all called via AsyncDo).

I've tried using InstAUX.CreateStdRangeProgressMon[Ex]() but progress dialog does *not* come up (I have ensured code execution is slow).

Any more coding required for CreateStdRangeProgressMon to work as expected?

-žarko

[Sasha - Tracker Dev Team]

Hello zarkogajic,

How do you imagine 5 separate progress dialogs running at the same time?
Probably you can use one parent progress dialog and let the operation use it's parts as a subprogress.
Basically what this means is telling the operation, that it's duration is 10 from 100. For that we have the IAUX_Inst::CreateStdRangeProgressMon method. But, that will work if you have a operation, that is being launched in the separate thread and it calls few other operations in the same thread.
In your case, this will be harder, as you are launching all of the operations from the different threads in parallel. How I see that this can be done is you will need one wrapper operation of some sort that will create and show the progress and will wait for all other operations to finish. Meanwhile, you will have an atomic progress position counter that will be increased from each operation while it's doing it's work. Basically you should pass an object of that progress to each of the operation, and also pass a delta that will tell how much duration it can fill from the 100%. This will allow to increase the progress position from each operation simultaneously, as the counter would be atomic (if not - just use the critical section of some sort).

Cheers,
Alex

[zarkogajic]

Hi Alex,

How do you imagine 5 separate progress dialogs running at the same time?

An example would be how Windows does copy operation for multiple copy operations. Older Windows versions would display separate "standalone" progress dialogs for each copy operation. Newer Windows would have one dialog with multiple progress bars.

Probably you can use one parent progress dialog and let the operation use it's parts as a subprogress... For that we have the IAUX_Inst::CreateStdRangeProgressMon method.... But, that will work if you have a operation, that is being launched in the separate thread and it calls few other operations in the same thread.

Thanks for explanation , but I still do not quite get the idea of CreateStdRangeProgressMon for *one* "multi step" operation (never mind now I'm running multiple operations in parallel)

If I would have as above, one "parent" operation with multiple "child" operations, why not simply use Inst.DefaultProgressMon ? Say the "parent" operation does 3 "separate" operations (in the same thread). Op1 has 3 steps, Op2 has 10 steps and Op3 has 7 steps. In total that is 20 steps. I could set Duration to 20 and simply set the Pos one step at the time: first 3 steps while Op1, then +10 steps while Op2 and finally +7 steps for Op3.

I do not see why, in the above, I would need to use CreateStdRangeProgressMon?

p.s.
Anyhow, what I'm doing right now is: using DefaultProgressMon. In each step of every operation (being run in different threads) I'm setting both the Duration and the Pos (and Text, Title) related to the "current" operation.

This works.

Yes, it has a weird looking effect since you constantly see progress values (both pos and duration and therefore %) being changed - but it is usable and does provide some feedback.

-žarko

[Sasha - Tracker Dev Team]

Hello zarkogajic,

You wont need the CreateStdRangeProgressMon as I mentioned earlier - it won't work for your case correctly.

Cheers,
Alex

[zarkogajic]

Hi Alex,

Please *ignore* my case (multiple parallel operations).

I do not see why/when I would need to use CreateStdRangeProgressMon. When, how I explained it, all can be done via DefaultProgressMon.

-žarko

[Sasha - Tracker Dev Team]

Hello zarkogajic,

Imaging that you have an operation that calls 3 more operations inside. Each operation is a black box that does something. All it has is a parameter where you can pass a progress. The question is how to tell those operation what duration should they use inside of it. For example, one of them works with 1243 pages, other goes through the bookmarks, and another one gets named destinations. All of them have different durations and types of items. Thus when we have a parent progress we should create a child progress and set the duration of it in terms of the parent progresses duration. Meaning, you can set the duration of the parent progress to 100 and 20, 10 and 70 will go to the sub progresses. All of those operation will get the subprogress interface from the passed parameter and will use it as a normal progress inside (for example set the duration for 1243 pages). All of this will result, that the 1243 pages passing will be only 20 points of duration on the main progress.

Cheers,
Alex

[zarkogajic]

HI Alex,

Thanks. But I must be missing something. I do understand what you are saying, but:

I still think this all can be done via DefaultProgressMon - all those 3 operations have access to it and can set the step.

you can set the duration of the parent progress to 100 and 20, 10 and 70..

Yes, I can set the duration of DefaultProgressMon to 100. First 20 moves will be done by "child" operation 1, next 10 by Child2 and finally last 70 by Child3. They are in the same thread so they are executed sequentially.

If Child1 goes over 1243 pages it can still move only 20 steps in the (main) progress bar (so not one step for each page).

I guess the easiest to understand and clear out misunderstanding on my side (obviously) would be if there's some sample code for the CreateStdRangeProgressMon usage?

-žarko

[Sasha - Tracker Dev Team]

Hello zarkogajic,

The thing is you don't have access to the operation's black box, and you can't tweak it's inner work. You only can pass the progress it can use. That's the main point of the subprogress. The operation don't know about you parent progress or anything else, it just does it's work,.

Cheers,
Alex

[zarkogajic]

Hi Alex,

Thanks.

A simple example, even if pseudo code, if possible?

-ž

[Sasha - Tracker Dev Team]

Hello zarkogajic,

Code: Select all

//Do() method of the operation
//...
//IProgressMon* pProgressMon
//get_DefaultProgressMon(pProgressMon)
//pProgressMon->put_Duration(100)
//pProgressMon->Start()
//...
//IProgressMon* pChild1
//iauxInst->CreateStdRangeProgressMon(pProgressMon, 15, &pChild1)
//DoSomeInnerStuff1(pChild1)
//...
////IProgressMon* pChild2
//iauxInst->CreateStdRangeProgressMon(pProgressMon, 45, &pChild2)
//DoSomeInnerStuff2(pChild2)
//...
////IProgressMon* pChild3
//iauxInst->CreateStdRangeProgressMon(pProgressMon, 40, &pChild3)
//DoSomeInnerStuff3(pChild3)
//...
//pProgressMon->Stop()

Note, that the parent progress has it's duration and it decides how much duration should each of the operations have, unlike the behavior that you are doing - each of the operation that you are using is taking 1 point of the parent's duration. In this case, when you are using the subprogress, the child operations work like they have been working before that.

Cheers,
Alex

[zarkogajic]

Hi Alex,

All clear now, thanks.

-žarko

[Sasha - Tracker Dev Team]