Time Critical Process in .NET

[CMM]

Re: Time Critical Process in .NET

His foremost problem is definately the RtfTextBox. Out of curiosity, I did a
simple test that appended several hundred lines to the control... after two
minutes the loop still wasn't done and I just stopped it. I wasn't even
formatting the text (color, font, etc) after appending it. I even used
BeginUpdate and stuff to keep it from redrawing until the loop was done.

Just like the TreeView control, the RtfTextBox seems like a very slooowww
control for whatever reason and certainly not usable for *frequent updates.*

P.S. Charles mentioned something about HTML. There is no intrinsic .NET
control to display HTML. You'd need to use WebBrowser ActiveX control...
chances are that it will be as slow as the RtfTextBox. I just can't see why
you can't write the control yourself... it seems like such a simple set of
requirements.

1) Keep statuses in a collection.
2) Tie the collection to a VScrollbar
3) Draw the items on a UserControl surface's OnPaint using DrawString.

*Pseudocode*:
Sub OnPaint
posY = VScrollBar1.Val ue
Do Until posY > Me.ClientRectan gle.Bottom or posY > Items.Count
DrawString(Item s.Item(posY)
posY += 1
Loop
End Sub

You get the idea. The only tricky part is supporting user "selection" so
that they can copy stuff to the clipboard. But even that is possible with a
little more work.


"Jay B. Harlow [MVP - Outlook]" wrote:
[color=blue]
> Charles,[color=green][color=darkred]
> >> I'm concerned you are treating symptoms rather then treating the illness
> >> itself. :-|[/color]
> >
> > I wasn't aware that I was. Surely the illness is displaying too much data,[/color]
>
> I thought the illness was that your task takes too long:
>
> <quote>
> The problem I have is that sometimes, for no apparent reason, a step in my
> process takes an inordinate amount of time, e.g 2.5 seconds instead of
> perhaps 300 ms.
> </quote>
>
> Of course the fact your task takes too long may be a symptom of a different
> problem... such as the alleged display problem.
>
> I have not seen anything that definitely suggests to me the problem is the
> display itself. Although I will admit it is one of my prime candidates ;-)
>
> Quirky little chicken & egg problem isn't it ;-)
>
> Just a thought
> Jay
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:O$p$gQrMFH A.1500@TK2MSFTN GP09.phx.gbl...[color=green]
> >
> > Jay
> >[color=darkred]
> >> I'm concerned you are treating symptoms rather then treating the illness
> >> itself. :-|[/color]
> >
> > I wasn't aware that I was. Surely the illness is displaying too much data,
> > which I am addressing. I was just bemoaning the fact that the original
> > solution had its benefits, so now I have to regain those benefits by some
> > other means.
> >[color=darkred]
> >> It should not be that hard to create an RtfTextWriter class (ala
> >> XmlTextWriter or HtmlTextWriter classes). That would encapsulate writing
> >> formatted RTF to a text file (Stream). I would expect creating an
> >> RtfTextReader would be more work...[/color]
> >
> > I don't actually want to go down this route. I fancy someone somewhere
> > must have done this already. I just need to find it! You have prompted me
> > to try html though. That could be quicker and, as I know html, easier too.
> > It doesn't have to be rtf. The main requirement is that however I save the
> > data, it can be displayed outside my app, but retaining the colour coding.
> >
> > Charles
> >
> >[/color]
> <<snip>>
>
>
>[/color]

[Cor Ligthert]

Re: Time Critical Process in .NET

CMM,
[color=blue]
> P.S. Charles mentioned something about HTML. There is no intrinsic .NET
> control to display HTML. You'd need to use WebBrowser ActiveX control...
> chances are that it will be as slow as the RtfTextBox. I just can't see
> why
> you can't write the control yourself... it seems like such a simple set of
> requirements[/color]

There is probably noboby (from the actives in these both newsgroups) who
knows more from the Webbrowser than Charles.

:-)

Cor

[Charles Law]

Re: Time Critical Process in .NET

Jay
[color=blue]
> I thought the illness was that your task takes too long:[/color]

I wasn't going back that far but, yes, you are right. The difficulty in
diagnosing that part of the problem is infrequent access to the target
equipment. I can't satisfactorily replicate the conditions without it.

I am not able yet to blame it all on the RTB, but when I stopped writing
messages to it every 50 ms I stopped overrunning my time window. I can't
remember without looking back over this thread whether I explained that I
have a couple of seconds in which to complete a process There might be 20
messages that I display in that time. When I display them in a RTB my
background process can occasionally take more than 2 seconds. If I don't
display them then it never seems to take longer than 800 ms, say. This is
odd because I use BeginInvoke on the RTB, so I would expect the display
process not to hold up my background task. But it seems to sometimes.

What I haven't been able to test yet is whether replacing the RTB with a
ListView overcomes the problem. It is certainly very much quicker, but if
BeginInvoke were doing its job then it wouldn't matter.

Anyway, that is why I am now considering outputting less data. I consider
that it may be too difficult/time consuming to actually fix the problem, so
I am looking to change the conditions sufficiently so that the problem goes
away. Not very scientific, I know, but just a smattering of pragmatism.

Charles


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:up3j6XwMFH A.244@tk2msftng p13.phx.gbl...[color=blue]
> Charles,[color=green][color=darkred]
>>> I'm concerned you are treating symptoms rather then treating the illness
>>> itself. :-|[/color]
>>
>> I wasn't aware that I was. Surely the illness is displaying too much
>> data,[/color]
>
> I thought the illness was that your task takes too long:
>
> <quote>
> The problem I have is that sometimes, for no apparent reason, a step in my
> process takes an inordinate amount of time, e.g 2.5 seconds instead of
> perhaps 300 ms.
> </quote>
>
> Of course the fact your task takes too long may be a symptom of a
> different problem... such as the alleged display problem.
>
> I have not seen anything that definitely suggests to me the problem is the
> display itself. Although I will admit it is one of my prime candidates ;-)
>
> Quirky little chicken & egg problem isn't it ;-)
>
> Just a thought
> Jay
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:O$p$gQrMFH A.1500@TK2MSFTN GP09.phx.gbl...[color=green]
>>
>> Jay
>>[color=darkred]
>>> I'm concerned you are treating symptoms rather then treating the illness
>>> itself. :-|[/color]
>>
>> I wasn't aware that I was. Surely the illness is displaying too much
>> data, which I am addressing. I was just bemoaning the fact that the
>> original solution had its benefits, so now I have to regain those
>> benefits by some other means.
>>[color=darkred]
>>> It should not be that hard to create an RtfTextWriter class (ala
>>> XmlTextWriter or HtmlTextWriter classes). That would encapsulate writing
>>> formatted RTF to a text file (Stream). I would expect creating an
>>> RtfTextReader would be more work...[/color]
>>
>> I don't actually want to go down this route. I fancy someone somewhere
>> must have done this already. I just need to find it! You have prompted me
>> to try html though. That could be quicker and, as I know html, easier
>> too. It doesn't have to be rtf. The main requirement is that however I
>> save the data, it can be displayed outside my app, but retaining the
>> colour coding.
>>
>> Charles
>>
>>[/color]
> <<snip>>
>[/color]