"Charles Law" <bl***@nowhere.com> wrote in message
news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
> Hi guys
>
> I have a time critical process, running on a worker thread. By "time
> critical", I mean that certain parts of the process must be completed in a
> specific time frame. The time when the process starts is not especially
> important, but it must be complete within a small number of seconds.
>
> The operations I am performing do not take a long time (hundreds of
> milliseconds), but as each part of the process is complete, my worker
> thread raises an event that is handled by the UI thread, to update a rich
> text control with details of the completed operation. I am using a rich
> text box so that when a failure occurs I can colour the message red.
>
> 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. When this happens, the complete process overruns my time
> frame, and it has to be repeated. When I repeat the process there is every
> chance that it completes in a realistic time, and all is well. If I stop
> outputting to the screen, I do not get the problem.
>
> When updating the screen on the UI thread, I use BeginInvoke, to marshal
> the operation to the correct thread, and so as not to hold up the worker
> thread, but this does not seem to help.
>
> I realise that Windows (XP in this case) is not the ideal o/s for this
> type of application, but does anyone have any ideas about how I could make
> my application more deterministic? I am not certain what is going on in
> these 2.5 seconds, so it might be useful if I could find out, but I am not
> sure how I would do that.
>
> TIA
>
> Charles
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
> Hi guys
>
> I have a time critical process, running on a worker thread. By "time
> critical", I mean that certain parts of the process must be completed in a
> specific time frame. The time when the process starts is not especially
> important, but it must be complete within a small number of seconds.
>
> The operations I am performing do not take a long time (hundreds of
> milliseconds), but as each part of the process is complete, my worker
> thread raises an event that is handled by the UI thread, to update a rich
> text control with details of the completed operation. I am using a rich
> text box so that when a failure occurs I can colour the message red.
>
> 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. When this happens, the complete process overruns my time
> frame, and it has to be repeated. When I repeat the process there is every
> chance that it completes in a realistic time, and all is well. If I stop
> outputting to the screen, I do not get the problem.
>
> When updating the screen on the UI thread, I use BeginInvoke, to marshal
> the operation to the correct thread, and so as not to hold up the worker
> thread, but this does not seem to help.
>
> I realise that Windows (XP in this case) is not the ideal o/s for this
> type of application, but does anyone have any ideas about how I could make
> my application more deterministic? I am not certain what is going on in
> these 2.5 seconds, so it might be useful if I could find out, but I am not
> sure how I would do that.
>
> TIA
>
> Charles
>
>

"Charles Law" wrote:

> I can't remember where I got up to with this thread, so this is a general
> update on the problem.
>
> I ran the application again this morning, against the real equipment. The
> time critical parts of the process now seem to be more stable, after
> implementing some of the suggestions, but at the severe detriment to the UI.
> As mentioned before, the background process raises events when it wants to
> notify the UI that something has happened, and the event handler marshals
> the event onto the UI thread, using a delegate and BeginInvoke, and appends
> the message to a rich text box.
>
> The problem is now that the screen appears to be updating at a reasonable
> pace, but it is clearly lagging a long way behind the messages being
> supplied to it. At its worst, the background process finished, and it took
> over five minutes for the screen to catch up. FIVE MINUTES! I think I have
> got my pattern wrong here. I don't mind the screen lagging slightly behind,
> but five minutes is just silly.
>
> Going back to basics, I want to (need to) capture the messages passed in all
> the events that the background thread raises, and I want to maintain a
> display of these messages. Some messages will be coloured red to make them
> stand out to the user, which is why I have used a rich text box.
>
> Is there a better pattern for this type of application?
>
> Incidentally, I ran this on a 3.0 GHz P4 Dell  laptop, not the slower
> Celeron m/c, so it will be much worse on the intended target m/c.
>
> Charles
>
>
> "Charles Law" <bl***@nowhere.com> wrote in message
> news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
> > Hi guys
> >
> > I have a time critical process, running on a worker thread. By "time
> > critical", I mean that certain parts of the process must be completed in a
> > specific time frame. The time when the process starts is not especially
> > important, but it must be complete within a small number of seconds.
> >
> > The operations I am performing do not take a long time (hundreds of
> > milliseconds), but as each part of the process is complete, my worker
> > thread raises an event that is handled by the UI thread, to update a rich
> > text control with details of the completed operation. I am using a rich
> > text box so that when a failure occurs I can colour the message red.
> >
> > 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. When this happens, the complete process overruns my time
> > frame, and it has to be repeated. When I repeat the process there is every
> > chance that it completes in a realistic time, and all is well. If I stop
> > outputting to the screen, I do not get the problem.
> >
> > When updating the screen on the UI thread, I use BeginInvoke, to marshal
> > the operation to the correct thread, and so as not to hold up the worker
> > thread, but this does not seem to help.
> >
> > I realise that Windows (XP in this case) is not the ideal o/s for this
> > type of application, but does anyone have any ideas about how I could make
> > my application more deterministic? I am not certain what is going on in
> > these 2.5 seconds, so it might be useful if I could find out, but I am not
> > sure how I would do that.
> >
> > TIA
> >
> > Charles
> >
> >
>
>
>

"CMM" <C**@discussions.microsoft.com> wrote in message
news:CB444FB8-B89B-4778-86BB-30A74A3F2DB7@microsoft.com...
> Your problems seems to be basically this:
>
> Your rich edit UI update is too sloooow. BeginInvoke queues up calls to
> maintain thread safety. The best solution IMHO is the "polling" technique
> I
> suggested earlier.
>
> 1) Worker thread SyncLocks a stack and pushes stuff into it.
> 2) UI Timer set at a reasonable interval (1 second maybe) SyncLocks the
> stack, pops stuff out (*without* updating the UI I may add!) and lets go
> of
> the SyncLock and then updates the UI... very nice, quick, and elegant.
> Much
> better than updating the UI in realtime and on-demand... which apparently
> is
> not working the way you want it to.
> 3) Everyone is happy. At most the UI is a second or so behind the
> workthread's actual status.
>
>
> "Charles Law" wrote:
>
>> I can't remember where I got up to with this thread, so this is a general
>> update on the problem.
>>
>> I ran the application again this morning, against the real equipment. The
>> time critical parts of the process now seem to be more stable, after
>> implementing some of the suggestions, but at the severe detriment to the
>> UI.
>> As mentioned before, the background process raises events when it wants
>> to
>> notify the UI that something has happened, and the event handler marshals
>> the event onto the UI thread, using a delegate and BeginInvoke, and
>> appends
>> the message to a rich text box.
>>
>> The problem is now that the screen appears to be updating at a reasonable
>> pace, but it is clearly lagging a long way behind the messages being
>> supplied to it. At its worst, the background process finished, and it
>> took
>> over five minutes for the screen to catch up. FIVE MINUTES! I think I
>> have
>> got my pattern wrong here. I don't mind the screen lagging slightly
>> behind,
>> but five minutes is just silly.
>>
>> Going back to basics, I want to (need to) capture the messages passed in
>> all
>> the events that the background thread raises, and I want to maintain a
>> display of these messages. Some messages will be coloured red to make
>> them
>> stand out to the user, which is why I have used a rich text box.
>>
>> Is there a better pattern for this type of application?
>>
>> Incidentally, I ran this on a 3.0 GHz P4 Dell  laptop, not the slower
>> Celeron m/c, so it will be much worse on the intended target m/c.
>>
>> Charles
>>
>>
>> "Charles Law" <bl***@nowhere.com> wrote in message
>> news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
>> > Hi guys
>> >
>> > I have a time critical process, running on a worker thread. By "time
>> > critical", I mean that certain parts of the process must be completed
>> > in a
>> > specific time frame. The time when the process starts is not especially
>> > important, but it must be complete within a small number of seconds.
>> >
>> > The operations I am performing do not take a long time (hundreds of
>> > milliseconds), but as each part of the process is complete, my worker
>> > thread raises an event that is handled by the UI thread, to update a
>> > rich
>> > text control with details of the completed operation. I am using a rich
>> > text box so that when a failure occurs I can colour the message red.
>> >
>> > 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. When this happens, the complete process overruns my
>> > time
>> > frame, and it has to be repeated. When I repeat the process there is
>> > every
>> > chance that it completes in a realistic time, and all is well. If I
>> > stop
>> > outputting to the screen, I do not get the problem.
>> >
>> > When updating the screen on the UI thread, I use BeginInvoke, to
>> > marshal
>> > the operation to the correct thread, and so as not to hold up the
>> > worker
>> > thread, but this does not seem to help.
>> >
>> > I realise that Windows (XP in this case) is not the ideal o/s for this
>> > type of application, but does anyone have any ideas about how I could
>> > make
>> > my application more deterministic? I am not certain what is going on in
>> > these 2.5 seconds, so it might be useful if I could find out, but I am
>> > not
>> > sure how I would do that.
>> >
>> > TIA
>> >
>> > Charles
>> >
>> >
>>
>>
>>

"Charles Law" wrote:

> I can't remember where I got up to with this thread, so this is a general
> update on the problem.
>
> I ran the application again this morning, against the real equipment. The
> time critical parts of the process now seem to be more stable, after
> implementing some of the suggestions, but at the severe detriment to the UI.
> As mentioned before, the background process raises events when it wants to
> notify the UI that something has happened, and the event handler marshals
> the event onto the UI thread, using a delegate and BeginInvoke, and appends
> the message to a rich text box.
>
> The problem is now that the screen appears to be updating at a reasonable
> pace, but it is clearly lagging a long way behind the messages being
> supplied to it. At its worst, the background process finished, and it took
> over five minutes for the screen to catch up. FIVE MINUTES! I think I have
> got my pattern wrong here. I don't mind the screen lagging slightly behind,
> but five minutes is just silly.
>
> Going back to basics, I want to (need to) capture the messages passed in all
> the events that the background thread raises, and I want to maintain a
> display of these messages. Some messages will be coloured red to make them
> stand out to the user, which is why I have used a rich text box.
>
> Is there a better pattern for this type of application?
>
> Incidentally, I ran this on a 3.0 GHz P4 Dell  laptop, not the slower
> Celeron m/c, so it will be much worse on the intended target m/c.
>
> Charles
>
>
> "Charles Law" <bl***@nowhere.com> wrote in message
> news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
> > Hi guys
> >
> > I have a time critical process, running on a worker thread. By "time
> > critical", I mean that certain parts of the process must be completed in a
> > specific time frame. The time when the process starts is not especially
> > important, but it must be complete within a small number of seconds.
> >
> > The operations I am performing do not take a long time (hundreds of
> > milliseconds), but as each part of the process is complete, my worker
> > thread raises an event that is handled by the UI thread, to update a rich
> > text control with details of the completed operation. I am using a rich
> > text box so that when a failure occurs I can colour the message red.
> >
> > 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. When this happens, the complete process overruns my time
> > frame, and it has to be repeated. When I repeat the process there is every
> > chance that it completes in a realistic time, and all is well. If I stop
> > outputting to the screen, I do not get the problem.
> >
> > When updating the screen on the UI thread, I use BeginInvoke, to marshal
> > the operation to the correct thread, and so as not to hold up the worker
> > thread, but this does not seem to help.
> >
> > I realise that Windows (XP in this case) is not the ideal o/s for this
> > type of application, but does anyone have any ideas about how I could make
> > my application more deterministic? I am not certain what is going on in
> > these 2.5 seconds, so it might be useful if I could find out, but I am not
> > sure how I would do that.
> >
> > TIA
> >
> > Charles
> >
> >
>
>
>

"CMM" <C**@discussions.microsoft.com> wrote in message
news:CB444FB8-B89B-4778-86BB-30A74A3F2DB7@microsoft.com...
> Your problems seems to be basically this:
>
> Your rich edit UI update is too sloooow. BeginInvoke queues up calls to
> maintain thread safety. The best solution IMHO is the "polling" technique
> I
> suggested earlier.
>
> 1) Worker thread SyncLocks a stack and pushes stuff into it.
> 2) UI Timer set at a reasonable interval (1 second maybe) SyncLocks the
> stack, pops stuff out (*without* updating the UI I may add!) and lets go
> of
> the SyncLock and then updates the UI... very nice, quick, and elegant.
> Much
> better than updating the UI in realtime and on-demand... which apparently
> is
> not working the way you want it to.
> 3) Everyone is happy. At most the UI is a second or so behind the
> workthread's actual status.
>
>
> "Charles Law" wrote:
>
>> I can't remember where I got up to with this thread, so this is a general
>> update on the problem.
>>
>> I ran the application again this morning, against the real equipment. The
>> time critical parts of the process now seem to be more stable, after
>> implementing some of the suggestions, but at the severe detriment to the
>> UI.
>> As mentioned before, the background process raises events when it wants
>> to
>> notify the UI that something has happened, and the event handler marshals
>> the event onto the UI thread, using a delegate and BeginInvoke, and
>> appends
>> the message to a rich text box.
>>
>> The problem is now that the screen appears to be updating at a reasonable
>> pace, but it is clearly lagging a long way behind the messages being
>> supplied to it. At its worst, the background process finished, and it
>> took
>> over five minutes for the screen to catch up. FIVE MINUTES! I think I
>> have
>> got my pattern wrong here. I don't mind the screen lagging slightly
>> behind,
>> but five minutes is just silly.
>>
>> Going back to basics, I want to (need to) capture the messages passed in
>> all
>> the events that the background thread raises, and I want to maintain a
>> display of these messages. Some messages will be coloured red to make
>> them
>> stand out to the user, which is why I have used a rich text box.
>>
>> Is there a better pattern for this type of application?
>>
>> Incidentally, I ran this on a 3.0 GHz P4 Dell  laptop, not the slower
>> Celeron m/c, so it will be much worse on the intended target m/c.
>>
>> Charles
>>
>>
>> "Charles Law" <bl***@nowhere.com> wrote in message
>> news:uuG%231YhKFHA.508@TK2MSFTNGP12.phx.gbl...
>> > Hi guys
>> >
>> > I have a time critical process, running on a worker thread. By "time
>> > critical", I mean that certain parts of the process must be completed
>> > in a
>> > specific time frame. The time when the process starts is not especially
>> > important, but it must be complete within a small number of seconds.
>> >
>> > The operations I am performing do not take a long time (hundreds of
>> > milliseconds), but as each part of the process is complete, my worker
>> > thread raises an event that is handled by the UI thread, to update a
>> > rich
>> > text control with details of the completed operation. I am using a rich
>> > text box so that when a failure occurs I can colour the message red.
>> >
>> > 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. When this happens, the complete process overruns my
>> > time
>> > frame, and it has to be repeated. When I repeat the process there is
>> > every
>> > chance that it completes in a realistic time, and all is well. If I
>> > stop
>> > outputting to the screen, I do not get the problem.
>> >
>> > When updating the screen on the UI thread, I use BeginInvoke, to
>> > marshal
>> > the operation to the correct thread, and so as not to hold up the
>> > worker
>> > thread, but this does not seem to help.
>> >
>> > I realise that Windows (XP in this case) is not the ideal o/s for this
>> > type of application, but does anyone have any ideas about how I could
>> > make
>> > my application more deterministic? I am not certain what is going on in
>> > these 2.5 seconds, so it might be useful if I could find out, but I am
>> > not
>> > sure how I would do that.
>> >
>> > TIA
>> >
>> > Charles
>> >
>> >
>>
>>
>>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:umYuCKUMFHA.244@tk2msftngp13.phx.gbl...
> Charles,
>
> Your listview is of course your solution.
>
> However reading this I get the idea that a solution could have been.
>
> Use a mainthread that updates your rtfbox.
>
> Use a workerthread that gets assynchronous the information from the
> workerthreads and passes that in whatever way assynchronous to the
> updating thread.
>
> Use your worker threads.
>
> Tell me what is wrong in this theoretical model.
>
> :-)
>
> Cor
>
>
>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:umYuCKUMFHA.244@tk2msftngp13.phx.gbl...
> Charles,
>
> Your listview is of course your solution.
>
> However reading this I get the idea that a solution could have been.
>
> Use a mainthread that updates your rtfbox.
>
> Use a workerthread that gets assynchronous the information from the
> workerthreads and passes that in whatever way assynchronous to the
> updating thread.
>
> Use your worker threads.
>
> Tell me what is wrong in this theoretical model.
>
> :-)
>
> Cor
>
>
>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> Charles,
>
> It has not to do with the way I told or others told
>
> This has to do with the design.
>
> When you use 3 instead of 2 tiers than you can let your loading of your
> RTFBox go smooth without any waiting in a seperated thread. Collect the
> information for that in another tier as well in a seperated thread. And
> let the worker tiers get the information for the last in as well seperated
> threads.
>
> This I can tell of course only now because we did not know that the RTFbox
> was the bottleneck.
>
> Describes this better what I mean?
>
> Cor
>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> Charles,
>
> It has not to do with the way I told or others told
>
> This has to do with the design.
>
> When you use 3 instead of 2 tiers than you can let your loading of your
> RTFBox go smooth without any waiting in a seperated thread. Collect the
> information for that in another tier as well in a seperated thread. And
> let the worker tiers get the information for the last in as well seperated
> threads.
>
> This I can tell of course only now because we did not know that the RTFbox
> was the bottleneck.
>
> Describes this better what I mean?
>
> Cor
>

"Charles Law" wrote:

> Ok, yes. I see what you mean.
>
> I think that one of the conclusions I should draw from this is that I am
> probably outputting too much information in the first instance. I know that
> sounds a bit like moving the goal posts, and that it doesn't solve the
> underlying problem should I wish to output that amount of data, but I am
> reminded of a similar situation put to me recently by a client. My answer
> was to display less information and allow the user to drill down when
> required, loading additional data as required. I think I should heed my own
> advice.
>
> I'm going to cache the large amount of output generated by the worker thread
> and just output headings. If the user wishes to get more detail I will load
> it when requested, in one hit. Nice and quick. I will also allow the entire
> output to be saved, at which time I can generate the rtf. [I'm still looking
> for a neat in-memory rtf generator. Maybe the rich text box will do it w/o
> making it visible]
>
> Thanks to everyone for their ideas and feedback.
>
> And thanks Cor.
>
> Charles
>
>
> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> > Charles,
> >
> > It has not to do with the way I told or others told
> >
> > This has to do with the design.
> >
> > When you use 3 instead of 2 tiers than you can let your loading of your
> > RTFBox go smooth without any waiting in a seperated thread. Collect the
> > information for that in another tier as well in a seperated thread. And
> > let the worker tiers get the information for the last in as well seperated
> > threads.
> >
> > This I can tell of course only now because we did not know that the RTFbox
> > was the bottleneck.
> >
> > Describes this better what I mean?
> >
> > Cor
> >
>
>
>

"Charles Law" wrote:

> Ok, yes. I see what you mean.
>
> I think that one of the conclusions I should draw from this is that I am
> probably outputting too much information in the first instance. I know that
> sounds a bit like moving the goal posts, and that it doesn't solve the
> underlying problem should I wish to output that amount of data, but I am
> reminded of a similar situation put to me recently by a client. My answer
> was to display less information and allow the user to drill down when
> required, loading additional data as required. I think I should heed my own
> advice.
>
> I'm going to cache the large amount of output generated by the worker thread
> and just output headings. If the user wishes to get more detail I will load
> it when requested, in one hit. Nice and quick. I will also allow the entire
> output to be saved, at which time I can generate the rtf. [I'm still looking
> for a neat in-memory rtf generator. Maybe the rich text box will do it w/o
> making it visible]
>
> Thanks to everyone for their ideas and feedback.
>
> And thanks Cor.
>
> Charles
>
>
> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> > Charles,
> >
> > It has not to do with the way I told or others told
> >
> > This has to do with the design.
> >
> > When you use 3 instead of 2 tiers than you can let your loading of your
> > RTFBox go smooth without any waiting in a seperated thread. Collect the
> > information for that in another tier as well in a seperated thread. And
> > let the worker tiers get the information for the last in as well seperated
> > threads.
> >
> > This I can tell of course only now because we did not know that the RTFbox
> > was the bottleneck.
> >
> > Describes this better what I mean?
> >
> > Cor
> >
>
>
>

"CMM" wrote:

> Good job testing out all of our flakey ideas. This was a very interesting and
> enlightening thread.
>
> Just one more suggestion: You are updating the RichTextbox by doing
> something like .Text = .Text + s and then using the Selection properties to
> set your formatting?
> This is your bottleneck I take it as it will exponentially become slower as
> the text increases. Have you taken a look at the RichTextBox's RTF property?
> This lets you set the whole text with codes... and would allow you to
> maintain your status messages in a StringBuilder complete with RTF codes that
> you would just dump into the control in one swoop (Text=sb.ToString() )
>
> RTF codes aren't that difficult... it's a lot like HTML... check out this
> link to get you started:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
>
>
> "Charles Law" wrote:
>
> > Ok, yes. I see what you mean.
> >
> > I think that one of the conclusions I should draw from this is that I am
> > probably outputting too much information in the first instance. I know that
> > sounds a bit like moving the goal posts, and that it doesn't solve the
> > underlying problem should I wish to output that amount of data, but I am
> > reminded of a similar situation put to me recently by a client. My answer
> > was to display less information and allow the user to drill down when
> > required, loading additional data as required. I think I should heed my own
> > advice.
> >
> > I'm going to cache the large amount of output generated by the worker thread
> > and just output headings. If the user wishes to get more detail I will load
> > it when requested, in one hit. Nice and quick. I will also allow the entire
> > output to be saved, at which time I can generate the rtf. [I'm still looking
> > for a neat in-memory rtf generator. Maybe the rich text box will do it w/o
> > making it visible]
> >
> > Thanks to everyone for their ideas and feedback.
> >
> > And thanks Cor.
> >
> > Charles
> >
> >
> > "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> > news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> > > Charles,
> > >
> > > It has not to do with the way I told or others told
> > >
> > > This has to do with the design.
> > >
> > > When you use 3 instead of 2 tiers than you can let your loading of your
> > > RTFBox go smooth without any waiting in a seperated thread. Collect the
> > > information for that in another tier as well in a seperated thread. And
> > > let the worker tiers get the information for the last in as well seperated
> > > threads.
> > >
> > > This I can tell of course only now because we did not know that the RTFbox
> > > was the bottleneck.
> > >
> > > Describes this better what I mean?
> > >
> > > Cor
> > >
> >
> >
> >

"CMM" wrote:

> Good job testing out all of our flakey ideas. This was a very interesting and
> enlightening thread.
>
> Just one more suggestion: You are updating the RichTextbox by doing
> something like .Text = .Text + s and then using the Selection properties to
> set your formatting?
> This is your bottleneck I take it as it will exponentially become slower as
> the text increases. Have you taken a look at the RichTextBox's RTF property?
> This lets you set the whole text with codes... and would allow you to
> maintain your status messages in a StringBuilder complete with RTF codes that
> you would just dump into the control in one swoop (Text=sb.ToString() )
>
> RTF codes aren't that difficult... it's a lot like HTML... check out this
> link to get you started:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
>
>
> "Charles Law" wrote:
>
> > Ok, yes. I see what you mean.
> >
> > I think that one of the conclusions I should draw from this is that I am
> > probably outputting too much information in the first instance. I know that
> > sounds a bit like moving the goal posts, and that it doesn't solve the
> > underlying problem should I wish to output that amount of data, but I am
> > reminded of a similar situation put to me recently by a client. My answer
> > was to display less information and allow the user to drill down when
> > required, loading additional data as required. I think I should heed my own
> > advice.
> >
> > I'm going to cache the large amount of output generated by the worker thread
> > and just output headings. If the user wishes to get more detail I will load
> > it when requested, in one hit. Nice and quick. I will also allow the entire
> > output to be saved, at which time I can generate the rtf. [I'm still looking
> > for a neat in-memory rtf generator. Maybe the rich text box will do it w/o
> > making it visible]
> >
> > Thanks to everyone for their ideas and feedback.
> >
> > And thanks Cor.
> >
> > Charles
> >
> >
> > "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> > news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> > > Charles,
> > >
> > > It has not to do with the way I told or others told
> > >
> > > This has to do with the design.
> > >
> > > When you use 3 instead of 2 tiers than you can let your loading of your
> > > RTFBox go smooth without any waiting in a seperated thread. Collect the
> > > information for that in another tier as well in a seperated thread. And
> > > let the worker tiers get the information for the last in as well seperated
> > > threads.
> > >
> > > This I can tell of course only now because we did not know that the RTFbox
> > > was the bottleneck.
> > >
> > > Describes this better what I mean?
> > >
> > > Cor
> > >
> >
> >
> >

"CMM" <C**@discussions.microsoft.com> wrote in message
news:CFEE1EBC-0DF3-4052-B5C5-2458A598EE89@microsoft.com...
> Good job testing out all of our flakey ideas. This was a very interesting
> and
> enlightening thread.
>
> Just one more suggestion: You are updating the RichTextbox by doing
> something like .Text = .Text + s and then using the Selection properties
> to
> set your formatting?
> This is your bottleneck I take it as it will exponentially become slower
> as
> the text increases. Have you taken a look at the RichTextBox's RTF
> property?
> This lets you set the whole text with codes... and would allow you to
> maintain your status messages in a StringBuilder complete with RTF codes
> that
> you would just dump into the control in one swoop (Text=sb.ToString() )
>
> RTF codes aren't that difficult... it's a lot like HTML... check out this
> link to get you started:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
>
>
> "Charles Law" wrote:
>
>> Ok, yes. I see what you mean.
>>
>> I think that one of the conclusions I should draw from this is that I am
>> probably outputting too much information in the first instance. I know
>> that
>> sounds a bit like moving the goal posts, and that it doesn't solve the
>> underlying problem should I wish to output that amount of data, but I am
>> reminded of a similar situation put to me recently by a client. My answer
>> was to display less information and allow the user to drill down when
>> required, loading additional data as required. I think I should heed my
>> own
>> advice.
>>
>> I'm going to cache the large amount of output generated by the worker
>> thread
>> and just output headings. If the user wishes to get more detail I will
>> load
>> it when requested, in one hit. Nice and quick. I will also allow the
>> entire
>> output to be saved, at which time I can generate the rtf. [I'm still
>> looking
>> for a neat in-memory rtf generator. Maybe the rich text box will do it
>> w/o
>> making it visible]
>>
>> Thanks to everyone for their ideas and feedback.
>>
>> And thanks Cor.
>>
>> Charles
>>
>>
>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> > Charles,
>> >
>> > It has not to do with the way I told or others told
>> >
>> > This has to do with the design.
>> >
>> > When you use 3 instead of 2 tiers than you can let your loading of your
>> > RTFBox go smooth without any waiting in a seperated thread. Collect the
>> > information for that in another tier as well in a seperated thread. And
>> > let the worker tiers get the information for the last in as well
>> > seperated
>> > threads.
>> >
>> > This I can tell of course only now because we did not know that the
>> > RTFbox
>> > was the bottleneck.
>> >
>> > Describes this better what I mean?
>> >
>> > Cor
>> >
>>
>>
>>

"Charles Law" wrote:

>
> > Just one more suggestion: You are updating the RichTextbox by doing
> > something like .Text = .Text + s and then using the Selection properties
> > to
> > set your formatting?
>
> The actual code is below (TestResults is the rich text box)
>
> <code>
>     Private Sub UpdateStatus(ByVal s As String)
>
>         Dim selectStart As Integer
>
>         With TestResults
>             .SuspendLayout()
>
>             .Focus()
>
>             selectStart = .TextLength
>
>             ' Append the status text to the results window
>             .AppendText(s & EOL)
>
>             ' Highlight failed tests in red
>             .SelectionColor = Color.Red
>
>             .Select(selectStart, s.Length)
>
>             .ClearUndo()
>
>             ' Keep the most recent addition in view
>             .Select(.TextLength, 0)
>             .ScrollToCaret()
>
>             .ResumeLayout()
>         End With
>
>     End Sub
> </code>
>
> > ... Have you taken a look at the RichTextBox's RTF property?
> > This lets you set the whole text with codes... and would allow you to
> > maintain your status messages in a StringBuilder complete with RTF codes
> > that
> > you would just dump into the control in one swoop (Text=sb.ToString() )
>
> Yes, I did look at the RTF property. I must admit that, despite your
> reassurances, it looked like  a lot of work. I know HTML well, but it did
> not seem quite so straight forward on first inspection. It may still be
> worth a punt though.
>
> Charles
>
>
> "CMM" <C**@discussions.microsoft.com> wrote in message
> news:CFEE1EBC-0DF3-4052-B5C5-2458A598EE89@microsoft.com...
> > Good job testing out all of our flakey ideas. This was a very interesting
> > and
> > enlightening thread.
> >
> > Just one more suggestion: You are updating the RichTextbox by doing
> > something like .Text = .Text + s and then using the Selection properties
> > to
> > set your formatting?
> > This is your bottleneck I take it as it will exponentially become slower
> > as
> > the text increases. Have you taken a look at the RichTextBox's RTF
> > property?
> > This lets you set the whole text with codes... and would allow you to
> > maintain your status messages in a StringBuilder complete with RTF codes
> > that
> > you would just dump into the control in one swoop (Text=sb.ToString() )
> >
> > RTF codes aren't that difficult... it's a lot like HTML... check out this
> > link to get you started:
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
> >
> >
> > "Charles Law" wrote:
> >
> >> Ok, yes. I see what you mean.
> >>
> >> I think that one of the conclusions I should draw from this is that I am
> >> probably outputting too much information in the first instance. I know
> >> that
> >> sounds a bit like moving the goal posts, and that it doesn't solve the
> >> underlying problem should I wish to output that amount of data, but I am
> >> reminded of a similar situation put to me recently by a client. My answer
> >> was to display less information and allow the user to drill down when
> >> required, loading additional data as required. I think I should heed my
> >> own
> >> advice.
> >>
> >> I'm going to cache the large amount of output generated by the worker
> >> thread
> >> and just output headings. If the user wishes to get more detail I will
> >> load
> >> it when requested, in one hit. Nice and quick. I will also allow the
> >> entire
> >> output to be saved, at which time I can generate the rtf. [I'm still
> >> looking
> >> for a neat in-memory rtf generator. Maybe the rich text box will do it
> >> w/o
> >> making it visible]
> >>
> >> Thanks to everyone for their ideas and feedback.
> >>
> >> And thanks Cor.
> >>
> >> Charles
> >>
> >>
> >> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> >> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> >> > Charles,
> >> >
> >> > It has not to do with the way I told or others told
> >> >
> >> > This has to do with the design.
> >> >
> >> > When you use 3 instead of 2 tiers than you can let your loading of your
> >> > RTFBox go smooth without any waiting in a seperated thread. Collect the
> >> > information for that in another tier as well in a seperated thread. And
> >> > let the worker tiers get the information for the last in as well
> >> > seperated
> >> > threads.
> >> >
> >> > This I can tell of course only now because we did not know that the
> >> > RTFbox
> >> > was the bottleneck.
> >> >
> >> > Describes this better what I mean?
> >> >
> >> > Cor
> >> >
> >>
> >>
> >>
>
>
>

"CMM" <C**@discussions.microsoft.com> wrote in message
news:CFEE1EBC-0DF3-4052-B5C5-2458A598EE89@microsoft.com...
> Good job testing out all of our flakey ideas. This was a very interesting
> and
> enlightening thread.
>
> Just one more suggestion: You are updating the RichTextbox by doing
> something like .Text = .Text + s and then using the Selection properties
> to
> set your formatting?
> This is your bottleneck I take it as it will exponentially become slower
> as
> the text increases. Have you taken a look at the RichTextBox's RTF
> property?
> This lets you set the whole text with codes... and would allow you to
> maintain your status messages in a StringBuilder complete with RTF codes
> that
> you would just dump into the control in one swoop (Text=sb.ToString() )
>
> RTF codes aren't that difficult... it's a lot like HTML... check out this
> link to get you started:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
>
>
> "Charles Law" wrote:
>
>> Ok, yes. I see what you mean.
>>
>> I think that one of the conclusions I should draw from this is that I am
>> probably outputting too much information in the first instance. I know
>> that
>> sounds a bit like moving the goal posts, and that it doesn't solve the
>> underlying problem should I wish to output that amount of data, but I am
>> reminded of a similar situation put to me recently by a client. My answer
>> was to display less information and allow the user to drill down when
>> required, loading additional data as required. I think I should heed my
>> own
>> advice.
>>
>> I'm going to cache the large amount of output generated by the worker
>> thread
>> and just output headings. If the user wishes to get more detail I will
>> load
>> it when requested, in one hit. Nice and quick. I will also allow the
>> entire
>> output to be saved, at which time I can generate the rtf. [I'm still
>> looking
>> for a neat in-memory rtf generator. Maybe the rich text box will do it
>> w/o
>> making it visible]
>>
>> Thanks to everyone for their ideas and feedback.
>>
>> And thanks Cor.
>>
>> Charles
>>
>>
>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> > Charles,
>> >
>> > It has not to do with the way I told or others told
>> >
>> > This has to do with the design.
>> >
>> > When you use 3 instead of 2 tiers than you can let your loading of your
>> > RTFBox go smooth without any waiting in a seperated thread. Collect the
>> > information for that in another tier as well in a seperated thread. And
>> > let the worker tiers get the information for the last in as well
>> > seperated
>> > threads.
>> >
>> > This I can tell of course only now because we did not know that the
>> > RTFbox
>> > was the bottleneck.
>> >
>> > Describes this better what I mean?
>> >
>> > Cor
>> >
>>
>>
>>

"CMM" <C**@discussions.microsoft.com> wrote in message
news:8E1E65F6-7A93-4EC4-A44B-5C2C557AD1D3@microsoft.com...
>I did a quick test to get a feel for how fast the RichTextBox would be
>using
> the Rtf property rather then the Text/Selection properties. It was still
> way
> slooooww. I say ditch the RichTextBox control.
>
>
> "Charles Law" wrote:
>
>>
>> > Just one more suggestion: You are updating the RichTextbox by doing
>> > something like .Text = .Text + s and then using the Selection
>> > properties
>> > to
>> > set your formatting?
>>
>> The actual code is below (TestResults is the rich text box)
>>
>> <code>
>>     Private Sub UpdateStatus(ByVal s As String)
>>
>>         Dim selectStart As Integer
>>
>>         With TestResults
>>             .SuspendLayout()
>>
>>             .Focus()
>>
>>             selectStart = .TextLength
>>
>>             ' Append the status text to the results window
>>             .AppendText(s & EOL)
>>
>>             ' Highlight failed tests in red
>>             .SelectionColor = Color.Red
>>
>>             .Select(selectStart, s.Length)
>>
>>             .ClearUndo()
>>
>>             ' Keep the most recent addition in view
>>             .Select(.TextLength, 0)
>>             .ScrollToCaret()
>>
>>             .ResumeLayout()
>>         End With
>>
>>     End Sub
>> </code>
>>
>> > ... Have you taken a look at the RichTextBox's RTF property?
>> > This lets you set the whole text with codes... and would allow you to
>> > maintain your status messages in a StringBuilder complete with RTF
>> > codes
>> > that
>> > you would just dump into the control in one swoop (Text=sb.ToString() )
>>
>> Yes, I did look at the RTF property. I must admit that, despite your
>> reassurances, it looked like  a lot of work. I know HTML well, but it did
>> not seem quite so straight forward on first inspection. It may still be
>> worth a punt though.
>>
>> Charles
>>
>>
>> "CMM" <C**@discussions.microsoft.com> wrote in message
>> news:CFEE1EBC-0DF3-4052-B5C5-2458A598EE89@microsoft.com...
>> > Good job testing out all of our flakey ideas. This was a very
>> > interesting
>> > and
>> > enlightening thread.
>> >
>> > Just one more suggestion: You are updating the RichTextbox by doing
>> > something like .Text = .Text + s and then using the Selection
>> > properties
>> > to
>> > set your formatting?
>> > This is your bottleneck I take it as it will exponentially become
>> > slower
>> > as
>> > the text increases. Have you taken a look at the RichTextBox's RTF
>> > property?
>> > This lets you set the whole text with codes... and would allow you to
>> > maintain your status messages in a StringBuilder complete with RTF
>> > codes
>> > that
>> > you would just dump into the control in one swoop (Text=sb.ToString() )
>> >
>> > RTF codes aren't that difficult... it's a lot like HTML... check out
>> > this
>> > link to get you started:
>> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
>> >
>> >
>> > "Charles Law" wrote:
>> >
>> >> Ok, yes. I see what you mean.
>> >>
>> >> I think that one of the conclusions I should draw from this is that I
>> >> am
>> >> probably outputting too much information in the first instance. I know
>> >> that
>> >> sounds a bit like moving the goal posts, and that it doesn't solve the
>> >> underlying problem should I wish to output that amount of data, but I
>> >> am
>> >> reminded of a similar situation put to me recently by a client. My
>> >> answer
>> >> was to display less information and allow the user to drill down when
>> >> required, loading additional data as required. I think I should heed
>> >> my
>> >> own
>> >> advice.
>> >>
>> >> I'm going to cache the large amount of output generated by the worker
>> >> thread
>> >> and just output headings. If the user wishes to get more detail I will
>> >> load
>> >> it when requested, in one hit. Nice and quick. I will also allow the
>> >> entire
>> >> output to be saved, at which time I can generate the rtf. [I'm still
>> >> looking
>> >> for a neat in-memory rtf generator. Maybe the rich text box will do it
>> >> w/o
>> >> making it visible]
>> >>
>> >> Thanks to everyone for their ideas and feedback.
>> >>
>> >> And thanks Cor.
>> >>
>> >> Charles
>> >>
>> >>
>> >> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>> >> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> >> > Charles,
>> >> >
>> >> > It has not to do with the way I told or others told
>> >> >
>> >> > This has to do with the design.
>> >> >
>> >> > When you use 3 instead of 2 tiers than you can let your loading of
>> >> > your
>> >> > RTFBox go smooth without any waiting in a seperated thread. Collect
>> >> > the
>> >> > information for that in another tier as well in a seperated thread.
>> >> > And
>> >> > let the worker tiers get the information for the last in as well
>> >> > seperated
>> >> > threads.
>> >> >
>> >> > This I can tell of course only now because we did not know that the
>> >> > RTFbox
>> >> > was the bottleneck.
>> >> >
>> >> > Describes this better what I mean?
>> >> >
>> >> > Cor
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

"Charles Law" wrote:

>
> > Just one more suggestion: You are updating the RichTextbox by doing
> > something like .Text = .Text + s and then using the Selection properties
> > to
> > set your formatting?
>
> The actual code is below (TestResults is the rich text box)
>
> <code>
>     Private Sub UpdateStatus(ByVal s As String)
>
>         Dim selectStart As Integer
>
>         With TestResults
>             .SuspendLayout()
>
>             .Focus()
>
>             selectStart = .TextLength
>
>             ' Append the status text to the results window
>             .AppendText(s & EOL)
>
>             ' Highlight failed tests in red
>             .SelectionColor = Color.Red
>
>             .Select(selectStart, s.Length)
>
>             .ClearUndo()
>
>             ' Keep the most recent addition in view
>             .Select(.TextLength, 0)
>             .ScrollToCaret()
>
>             .ResumeLayout()
>         End With
>
>     End Sub
> </code>
>
> > ... Have you taken a look at the RichTextBox's RTF property?
> > This lets you set the whole text with codes... and would allow you to
> > maintain your status messages in a StringBuilder complete with RTF codes
> > that
> > you would just dump into the control in one swoop (Text=sb.ToString() )
>
> Yes, I did look at the RTF property. I must admit that, despite your
> reassurances, it looked like  a lot of work. I know HTML well, but it did
> not seem quite so straight forward on first inspection. It may still be
> worth a punt though.
>
> Charles
>
>
> "CMM" <C**@discussions.microsoft.com> wrote in message
> news:CFEE1EBC-0DF3-4052-B5C5-2458A598EE89@microsoft.com...
> > Good job testing out all of our flakey ideas. This was a very interesting
> > and
> > enlightening thread.
> >
> > Just one more suggestion: You are updating the RichTextbox by doing
> > something like .Text = .Text + s and then using the Selection properties
> > to
> > set your formatting?
> > This is your bottleneck I take it as it will exponentially become slower
> > as
> > the text increases. Have you taken a look at the RichTextBox's RTF
> > property?
> > This lets you set the whole text with codes... and would allow you to
> > maintain your status messages in a StringBuilder complete with RTF codes
> > that
> > you would just dump into the control in one swoop (Text=sb.ToString() )
> >
> > RTF codes aren't that difficult... it's a lot like HTML... check out this
> > link to get you started:
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
> >
> >
> > "Charles Law" wrote:
> >
> >> Ok, yes. I see what you mean.
> >>
> >> I think that one of the conclusions I should draw from this is that I am
> >> probably outputting too much information in the first instance. I know
> >> that
> >> sounds a bit like moving the goal posts, and that it doesn't solve the
> >> underlying problem should I wish to output that amount of data, but I am
> >> reminded of a similar situation put to me recently by a client. My answer
> >> was to display less information and allow the user to drill down when
> >> required, loading additional data as required. I think I should heed my
> >> own
> >> advice.
> >>
> >> I'm going to cache the large amount of output generated by the worker
> >> thread
> >> and just output headings. If the user wishes to get more detail I will
> >> load
> >> it when requested, in one hit. Nice and quick. I will also allow the
> >> entire
> >> output to be saved, at which time I can generate the rtf. [I'm still
> >> looking
> >> for a neat in-memory rtf generator. Maybe the rich text box will do it
> >> w/o
> >> making it visible]
> >>
> >> Thanks to everyone for their ideas and feedback.
> >>
> >> And thanks Cor.
> >>
> >> Charles
> >>
> >>
> >> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> >> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> >> > Charles,
> >> >
> >> > It has not to do with the way I told or others told
> >> >
> >> > This has to do with the design.
> >> >
> >> > When you use 3 instead of 2 tiers than you can let your loading of your
> >> > RTFBox go smooth without any waiting in a seperated thread. Collect the
> >> > information for that in another tier as well in a seperated thread. And
> >> > let the worker tiers get the information for the last in as well
> >> > seperated
> >> > threads.
> >> >
> >> > This I can tell of course only now because we did not know that the
> >> > RTFbox
> >> > was the bottleneck.
> >> >
> >> > Describes this better what I mean?
> >> >
> >> > Cor
> >> >
> >>
> >>
> >>
>
>
>

"CMM" <C**@discussions.microsoft.com> wrote in message
news:8E1E65F6-7A93-4EC4-A44B-5C2C557AD1D3@microsoft.com...
>I did a quick test to get a feel for how fast the RichTextBox would be
>using
> the Rtf property rather then the Text/Selection properties. It was still
> way
> slooooww. I say ditch the RichTextBox control.
>
>
> "Charles Law" wrote:
>
>>
>> > Just one more suggestion: You are updating the RichTextbox by doing
>> > something like .Text = .Text + s and then using the Selection
>> > properties
>> > to
>> > set your formatting?
>>
>> The actual code is below (TestResults is the rich text box)
>>
>> <code>
>>     Private Sub UpdateStatus(ByVal s As String)
>>
>>         Dim selectStart As Integer
>>
>>         With TestResults
>>             .SuspendLayout()
>>
>>             .Focus()
>>
>>             selectStart = .TextLength
>>
>>             ' Append the status text to the results window
>>             .AppendText(s & EOL)
>>
>>             ' Highlight failed tests in red
>>             .SelectionColor = Color.Red
>>
>>             .Select(selectStart, s.Length)
>>
>>             .ClearUndo()
>>
>>             ' Keep the most recent addition in view
>>             .Select(.TextLength, 0)
>>             .ScrollToCaret()
>>
>>             .ResumeLayout()
>>         End With
>>
>>     End Sub
>> </code>
>>
>> > ... Have you taken a look at the RichTextBox's RTF property?
>> > This lets you set the whole text with codes... and would allow you to
>> > maintain your status messages in a StringBuilder complete with RTF
>> > codes
>> > that
>> > you would just dump into the control in one swoop (Text=sb.ToString() )
>>
>> Yes, I did look at the RTF property. I must admit that, despite your
>> reassurances, it looked like  a lot of work. I know HTML well, but it did
>> not seem quite so straight forward on first inspection. It may still be
>> worth a punt though.
>>
>> Charles
>>
>>
>> "CMM" <C**@discussions.microsoft.com> wrote in message
>> news:CFEE1EBC-0DF3-4052-B5C5-2458A598EE89@microsoft.com...
>> > Good job testing out all of our flakey ideas. This was a very
>> > interesting
>> > and
>> > enlightening thread.
>> >
>> > Just one more suggestion: You are updating the RichTextbox by doing
>> > something like .Text = .Text + s and then using the Selection
>> > properties
>> > to
>> > set your formatting?
>> > This is your bottleneck I take it as it will exponentially become
>> > slower
>> > as
>> > the text increases. Have you taken a look at the RichTextBox's RTF
>> > property?
>> > This lets you set the whole text with codes... and would allow you to
>> > maintain your status messages in a StringBuilder complete with RTF
>> > codes
>> > that
>> > you would just dump into the control in one swoop (Text=sb.ToString() )
>> >
>> > RTF codes aren't that difficult... it's a lot like HTML... check out
>> > this
>> > link to get you started:
>> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vbcode/html/vbtskCodeFormattingCharactersInBoldInRichTextBoxControlVisualBasic.asp
>> >
>> >
>> > "Charles Law" wrote:
>> >
>> >> Ok, yes. I see what you mean.
>> >>
>> >> I think that one of the conclusions I should draw from this is that I
>> >> am
>> >> probably outputting too much information in the first instance. I know
>> >> that
>> >> sounds a bit like moving the goal posts, and that it doesn't solve the
>> >> underlying problem should I wish to output that amount of data, but I
>> >> am
>> >> reminded of a similar situation put to me recently by a client. My
>> >> answer
>> >> was to display less information and allow the user to drill down when
>> >> required, loading additional data as required. I think I should heed
>> >> my
>> >> own
>> >> advice.
>> >>
>> >> I'm going to cache the large amount of output generated by the worker
>> >> thread
>> >> and just output headings. If the user wishes to get more detail I will
>> >> load
>> >> it when requested, in one hit. Nice and quick. I will also allow the
>> >> entire
>> >> output to be saved, at which time I can generate the rtf. [I'm still
>> >> looking
>> >> for a neat in-memory rtf generator. Maybe the rich text box will do it
>> >> w/o
>> >> making it visible]
>> >>
>> >> Thanks to everyone for their ideas and feedback.
>> >>
>> >> And thanks Cor.
>> >>
>> >> Charles
>> >>
>> >>
>> >> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>> >> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> >> > Charles,
>> >> >
>> >> > It has not to do with the way I told or others told
>> >> >
>> >> > This has to do with the design.
>> >> >
>> >> > When you use 3 instead of 2 tiers than you can let your loading of
>> >> > your
>> >> > RTFBox go smooth without any waiting in a seperated thread. Collect
>> >> > the
>> >> > information for that in another tier as well in a seperated thread.
>> >> > And
>> >> > let the worker tiers get the information for the last in as well
>> >> > seperated
>> >> > threads.
>> >> >
>> >> > This I can tell of course only now because we did not know that the
>> >> > RTFbox
>> >> > was the bottleneck.
>> >> >
>> >> > Describes this better what I mean?
>> >> >
>> >> > Cor
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> Charles,
>
> It has not to do with the way I told or others told
>
> This has to do with the design.
>
> When you use 3 instead of 2 tiers than you can let your loading of your
> RTFBox go smooth without any waiting in a seperated thread. Collect the
> information for that in another tier as well in a seperated thread. And
> let the worker tiers get the information for the last in as well seperated
> threads.
>
> This I can tell of course only now because we did not know that the RTFbox
> was the bottleneck.
>
> Describes this better what I mean?
>
> Cor
>

"Jay B. Harlow [MVP - Outlook]" wrote:

> Cor & CMM,
> > This I can tell of course only now because we did not know that the RTFbox
> > was the bottleneck.
> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView is
> faster then the RTF Box, but that does not prove that the RTFBox is the
> bottle neck!
>
> The bottleneck may be the interop marshalling from .NET world to the Win32
> RTF Textbox world. In which case both the RTFBox & the ListView will have a
> problem as both are based on "native" Win32 controls.
>
> The bottleneck may be the GC!
>
> The bottleneck may actually be the way Charles' program is interacting with
> memory.
>
> The bottleneck may be some unrelated program that happens to be running.
>
> The bottleneck may be some unforseen disk access, such as page swapping.
>
> The bottleneck may be any number of other things...
>
> Hence my suggestion to use CLR Profiler & other tools to try to accurately
> identify where specifically the bottle neck is.
>
> Or at the very least two methods & see which is faster. However I have seen
> where one method may be faster for small number and/or size of objects,
> suddenly becomes painfully slow for large number and/or size of objects...
>
> As Charles initially stated "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." The "sometimes, for no apparent
> reason" would suggest to me that it is not specifically the RTF or the
> BeginInvoke, although it could be.
>
> In other words BeginInvoke & the RTF Box are both still suspects, however
> the jury (CLR Profiler) has not convicted them of any crime.
>
> Just a thought
> Jay
>
> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> > Charles,
> >
> > It has not to do with the way I told or others told
> >
> > This has to do with the design.
> >
> > When you use 3 instead of 2 tiers than you can let your loading of your
> > RTFBox go smooth without any waiting in a seperated thread. Collect the
> > information for that in another tier as well in a seperated thread. And
> > let the worker tiers get the information for the last in as well seperated
> > threads.
> >
> > This I can tell of course only now because we did not know that the RTFbox
> > was the bottleneck.
> >
> > Describes this better what I mean?
> >
> > Cor
> >
>
>
>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> Charles,
>
> It has not to do with the way I told or others told
>
> This has to do with the design.
>
> When you use 3 instead of 2 tiers than you can let your loading of your
> RTFBox go smooth without any waiting in a seperated thread. Collect the
> information for that in another tier as well in a seperated thread. And
> let the worker tiers get the information for the last in as well seperated
> threads.
>
> This I can tell of course only now because we did not know that the RTFbox
> was the bottleneck.
>
> Describes this better what I mean?
>
> Cor
>

"Jay B. Harlow [MVP - Outlook]" wrote:

> Cor & CMM,
> > This I can tell of course only now because we did not know that the RTFbox
> > was the bottleneck.
> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView is
> faster then the RTF Box, but that does not prove that the RTFBox is the
> bottle neck!
>
> The bottleneck may be the interop marshalling from .NET world to the Win32
> RTF Textbox world. In which case both the RTFBox & the ListView will have a
> problem as both are based on "native" Win32 controls.
>
> The bottleneck may be the GC!
>
> The bottleneck may actually be the way Charles' program is interacting with
> memory.
>
> The bottleneck may be some unrelated program that happens to be running.
>
> The bottleneck may be some unforseen disk access, such as page swapping.
>
> The bottleneck may be any number of other things...
>
> Hence my suggestion to use CLR Profiler & other tools to try to accurately
> identify where specifically the bottle neck is.
>
> Or at the very least two methods & see which is faster. However I have seen
> where one method may be faster for small number and/or size of objects,
> suddenly becomes painfully slow for large number and/or size of objects...
>
> As Charles initially stated "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." The "sometimes, for no apparent
> reason" would suggest to me that it is not specifically the RTF or the
> BeginInvoke, although it could be.
>
> In other words BeginInvoke & the RTF Box are both still suspects, however
> the jury (CLR Profiler) has not convicted them of any crime.
>
> Just a thought
> Jay
>
> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
> > Charles,
> >
> > It has not to do with the way I told or others told
> >
> > This has to do with the design.
> >
> > When you use 3 instead of 2 tiers than you can let your loading of your
> > RTFBox go smooth without any waiting in a seperated thread. Collect the
> > information for that in another tier as well in a seperated thread. And
> > let the worker tiers get the information for the last in as well seperated
> > threads.
> >
> > This I can tell of course only now because we did not know that the RTFbox
> > was the bottleneck.
> >
> > Describes this better what I mean?
> >
> > Cor
> >
>
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
> Cor & CMM,
>> This I can tell of course only now because we did not know that the
>> RTFbox was the bottleneck.
> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView
> is faster then the RTF Box, but that does not prove that the RTFBox is the
> bottle neck!
>
> The bottleneck may be the interop marshalling from .NET world to the Win32
> RTF Textbox world. In which case both the RTFBox & the ListView will have
> a problem as both are based on "native" Win32 controls.
>
> The bottleneck may be the GC!
>
> The bottleneck may actually be the way Charles' program is interacting
> with memory.
>
> The bottleneck may be some unrelated program that happens to be running.
>
> The bottleneck may be some unforseen disk access, such as page swapping.
>
> The bottleneck may be any number of other things...
>
> Hence my suggestion to use CLR Profiler & other tools to try to accurately
> identify where specifically the bottle neck is.
>
> Or at the very least two methods & see which is faster. However I have
> seen where one method may be faster for small number and/or size of
> objects, suddenly becomes painfully slow for large number and/or size of
> objects...
>
> As Charles initially stated "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." The "sometimes, for no
> apparent reason" would suggest to me that it is not specifically the RTF
> or the BeginInvoke, although it could be.
>
> In other words BeginInvoke & the RTF Box are both still suspects, however
> the jury (CLR Profiler) has not convicted them of any crime.
>
> Just a thought
> Jay
>
> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> Charles,
>>
>> It has not to do with the way I told or others told
>>
>> This has to do with the design.
>>
>> When you use 3 instead of 2 tiers than you can let your loading of your
>> RTFBox go smooth without any waiting in a seperated thread. Collect the
>> information for that in another tier as well in a seperated thread. And
>> let the worker tiers get the information for the last in as well
>> seperated threads.
>>
>> This I can tell of course only now because we did not know that the
>> RTFbox was the bottleneck.
>>
>> Describes this better what I mean?
>>
>> Cor
>>
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
> Cor & CMM,
>> This I can tell of course only now because we did not know that the
>> RTFbox was the bottleneck.
> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView
> is faster then the RTF Box, but that does not prove that the RTFBox is the
> bottle neck!
>
> The bottleneck may be the interop marshalling from .NET world to the Win32
> RTF Textbox world. In which case both the RTFBox & the ListView will have
> a problem as both are based on "native" Win32 controls.
>
> The bottleneck may be the GC!
>
> The bottleneck may actually be the way Charles' program is interacting
> with memory.
>
> The bottleneck may be some unrelated program that happens to be running.
>
> The bottleneck may be some unforseen disk access, such as page swapping.
>
> The bottleneck may be any number of other things...
>
> Hence my suggestion to use CLR Profiler & other tools to try to accurately
> identify where specifically the bottle neck is.
>
> Or at the very least two methods & see which is faster. However I have
> seen where one method may be faster for small number and/or size of
> objects, suddenly becomes painfully slow for large number and/or size of
> objects...
>
> As Charles initially stated "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." The "sometimes, for no
> apparent reason" would suggest to me that it is not specifically the RTF
> or the BeginInvoke, although it could be.
>
> In other words BeginInvoke & the RTF Box are both still suspects, however
> the jury (CLR Profiler) has not convicted them of any crime.
>
> Just a thought
> Jay
>
> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>> Charles,
>>
>> It has not to do with the way I told or others told
>>
>> This has to do with the design.
>>
>> When you use 3 instead of 2 tiers than you can let your loading of your
>> RTFBox go smooth without any waiting in a seperated thread. Collect the
>> information for that in another tier as well in a seperated thread. And
>> let the worker tiers get the information for the last in as well
>> seperated threads.
>>
>> This I can tell of course only now because we did not know that the
>> RTFbox was the bottleneck.
>>
>> Describes this better what I mean?
>>
>> Cor
>>
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
> Hi Jay
>
> I am convinced that the RichTextBox is /a/ bottleneck.
>
>> The bottleneck may be the GC!
>
> Interestingly, I noticed that in my tests, there was a noticeable pause
> early in the updating of he RTB. It contained only a dozen lines, but I
> detected a half-second pause as the screen was updating. This was
> reproducible. There is every chance that this would re-occur later, and
> when the RTB is fuller, the delay could be longer.
>
>> The bottleneck may actually be the way Charles' program is interacting
>> with memory.
>
> In my real-world application this is true. But my samples are trivial.
> Object creation is minimal, but it is true that in the event sample, an
> EventArgs object is created every time an event is raised.
>
>> The bottleneck may be some unrelated program that happens to be running.
>
> If this were true, I would expect it to affect both samples equally.
>
>> The bottleneck may be some unforeseen disk access, such as page swapping.
>
> As above.
>
>> The bottleneck may be any number of other things...
>
> I appreciate that you are illustrating the general point that the problem
> might lie elsewhere, somewhere that we have not considered, but I have
> attempted to make all things equal, so that the only differences in my
> samples are down to the detail of the test that I am conducting.
>
>> Hence my suggestion to use CLR Profiler & other tools to try to
>> accurately identify where specifically the bottle neck is.
>
> I have had another look at the CLR Profiler and I can only say that I
> understand now why it is free. There are many diverse requirements for
> memory profiling, but as far as I can see none of them are intuitively
> handled by the CLR Profiler.
>
>> As Charles initially stated "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." The "sometimes, for no
>> apparent reason" would suggest to me that it is not specifically the RTF
>> or the BeginInvoke, although it could be.
>
> Agreed, But it may be that because of the way the RTB is implemented there
> is a lot of memory manipulation going on that impairs performance.
>
>> In other words BeginInvoke & the RTF Box are both still suspects, however
>> the jury (CLR Profiler) has not convicted them of any crime.
>
> Also agreed.
>
> My gut feeling is that the RTB is not the best tool for the job that I
> started out with. That said, the job I started out with is probably quite
> a stretch full-stop. I suspect that I should take more control over the
> delivery of status to the user based on the amount of information I am
> trying to deliver. I am inclined to believe that the fundamental flaw is
> that I am trying to present too much information in a short space of time,
> with controls that are not designed for that kind of performance. I could
> probably write a more efficient control, but there would be a lot of
> functionality to reproduce, and it may not be necessary if I modify
> slightly my contact with the user.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
> news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>> Cor & CMM,
>>> This I can tell of course only now because we did not know that the
>>> RTFbox was the bottleneck.
>> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView
>> is faster then the RTF Box, but that does not prove that the RTFBox is
>> the bottle neck!
>>
>> The bottleneck may be the interop marshalling from .NET world to the
>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>> will have a problem as both are based on "native" Win32 controls.
>>
>> The bottleneck may be the GC!
>>
>> The bottleneck may actually be the way Charles' program is interacting
>> with memory.
>>
>> The bottleneck may be some unrelated program that happens to be running.
>>
>> The bottleneck may be some unforseen disk access, such as page swapping.
>>
>> The bottleneck may be any number of other things...
>>
>> Hence my suggestion to use CLR Profiler & other tools to try to
>> accurately identify where specifically the bottle neck is.
>>
>> Or at the very least two methods & see which is faster. However I have
>> seen where one method may be faster for small number and/or size of
>> objects, suddenly becomes painfully slow for large number and/or size of
>> objects...
>>
>> As Charles initially stated "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." The "sometimes, for no
>> apparent reason" would suggest to me that it is not specifically the RTF
>> or the BeginInvoke, although it could be.
>>
>> In other words BeginInvoke & the RTF Box are both still suspects, however
>> the jury (CLR Profiler) has not convicted them of any crime.
>>
>> Just a thought
>> Jay
>>
>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>> Charles,
>>>
>>> It has not to do with the way I told or others told
>>>
>>> This has to do with the design.
>>>
>>> When you use 3 instead of 2 tiers than you can let your loading of your
>>> RTFBox go smooth without any waiting in a seperated thread. Collect the
>>> information for that in another tier as well in a seperated thread. And
>>> let the worker tiers get the information for the last in as well
>>> seperated threads.
>>>
>>> This I can tell of course only now because we did not know that the
>>> RTFbox was the bottleneck.
>>>
>>> Describes this better what I mean?
>>>
>>> Cor
>>>
>>
>>
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
> Hi Jay
>
> I am convinced that the RichTextBox is /a/ bottleneck.
>
>> The bottleneck may be the GC!
>
> Interestingly, I noticed that in my tests, there was a noticeable pause
> early in the updating of he RTB. It contained only a dozen lines, but I
> detected a half-second pause as the screen was updating. This was
> reproducible. There is every chance that this would re-occur later, and
> when the RTB is fuller, the delay could be longer.
>
>> The bottleneck may actually be the way Charles' program is interacting
>> with memory.
>
> In my real-world application this is true. But my samples are trivial.
> Object creation is minimal, but it is true that in the event sample, an
> EventArgs object is created every time an event is raised.
>
>> The bottleneck may be some unrelated program that happens to be running.
>
> If this were true, I would expect it to affect both samples equally.
>
>> The bottleneck may be some unforeseen disk access, such as page swapping.
>
> As above.
>
>> The bottleneck may be any number of other things...
>
> I appreciate that you are illustrating the general point that the problem
> might lie elsewhere, somewhere that we have not considered, but I have
> attempted to make all things equal, so that the only differences in my
> samples are down to the detail of the test that I am conducting.
>
>> Hence my suggestion to use CLR Profiler & other tools to try to
>> accurately identify where specifically the bottle neck is.
>
> I have had another look at the CLR Profiler and I can only say that I
> understand now why it is free. There are many diverse requirements for
> memory profiling, but as far as I can see none of them are intuitively
> handled by the CLR Profiler.
>
>> As Charles initially stated "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." The "sometimes, for no
>> apparent reason" would suggest to me that it is not specifically the RTF
>> or the BeginInvoke, although it could be.
>
> Agreed, But it may be that because of the way the RTB is implemented there
> is a lot of memory manipulation going on that impairs performance.
>
>> In other words BeginInvoke & the RTF Box are both still suspects, however
>> the jury (CLR Profiler) has not convicted them of any crime.
>
> Also agreed.
>
> My gut feeling is that the RTB is not the best tool for the job that I
> started out with. That said, the job I started out with is probably quite
> a stretch full-stop. I suspect that I should take more control over the
> delivery of status to the user based on the amount of information I am
> trying to deliver. I am inclined to believe that the fundamental flaw is
> that I am trying to present too much information in a short space of time,
> with controls that are not designed for that kind of performance. I could
> probably write a more efficient control, but there would be a lot of
> functionality to reproduce, and it may not be necessary if I modify
> slightly my contact with the user.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
> news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>> Cor & CMM,
>>> This I can tell of course only now because we did not know that the
>>> RTFbox was the bottleneck.
>> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView
>> is faster then the RTF Box, but that does not prove that the RTFBox is
>> the bottle neck!
>>
>> The bottleneck may be the interop marshalling from .NET world to the
>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>> will have a problem as both are based on "native" Win32 controls.
>>
>> The bottleneck may be the GC!
>>
>> The bottleneck may actually be the way Charles' program is interacting
>> with memory.
>>
>> The bottleneck may be some unrelated program that happens to be running.
>>
>> The bottleneck may be some unforseen disk access, such as page swapping.
>>
>> The bottleneck may be any number of other things...
>>
>> Hence my suggestion to use CLR Profiler & other tools to try to
>> accurately identify where specifically the bottle neck is.
>>
>> Or at the very least two methods & see which is faster. However I have
>> seen where one method may be faster for small number and/or size of
>> objects, suddenly becomes painfully slow for large number and/or size of
>> objects...
>>
>> As Charles initially stated "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." The "sometimes, for no
>> apparent reason" would suggest to me that it is not specifically the RTF
>> or the BeginInvoke, although it could be.
>>
>> In other words BeginInvoke & the RTF Box are both still suspects, however
>> the jury (CLR Profiler) has not convicted them of any crime.
>>
>> Just a thought
>> Jay
>>
>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>> Charles,
>>>
>>> It has not to do with the way I told or others told
>>>
>>> This has to do with the design.
>>>
>>> When you use 3 instead of 2 tiers than you can let your loading of your
>>> RTFBox go smooth without any waiting in a seperated thread. Collect the
>>> information for that in another tier as well in a seperated thread. And
>>> let the worker tiers get the information for the last in as well
>>> seperated threads.
>>>
>>> This I can tell of course only now because we did not know that the
>>> RTFbox was the bottleneck.
>>>
>>> Describes this better what I mean?
>>>
>>> Cor
>>>
>>
>>
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:OcqtNCiMFHA.576@TK2MSFTNGP15.phx.gbl...
> Charles,
>> My gut feeling is that the RTB is not the best tool for the job that I
>> started out with.
> My gut feeling is the RTB is not the best tool for the job. However this
> is from a presentation standpoint & not a performance standpoint!
>
> It sounds like you are displaying when a series of events occurred in a
> process, a ListView (in Details mode) or a Grid sounds like a better fit.
>
>> I am inclined to believe that the fundamental flaw is that I am trying to
>> present too much information in a short space of time,
> Agreed
>
>> with controls that are not designed for that kind of performance.
> Depending on how short the "short space of time" is, there may not be a
> control worthy of the performance...
>
>
> Just a thought
> Jay
>
> "Charles Law" <bl***@nowhere.com> wrote in message
> news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
>> Hi Jay
>>
>> I am convinced that the RichTextBox is /a/ bottleneck.
>>
>>> The bottleneck may be the GC!
>>
>> Interestingly, I noticed that in my tests, there was a noticeable pause
>> early in the updating of he RTB. It contained only a dozen lines, but I
>> detected a half-second pause as the screen was updating. This was
>> reproducible. There is every chance that this would re-occur later, and
>> when the RTB is fuller, the delay could be longer.
>>
>>> The bottleneck may actually be the way Charles' program is interacting
>>> with memory.
>>
>> In my real-world application this is true. But my samples are trivial.
>> Object creation is minimal, but it is true that in the event sample, an
>> EventArgs object is created every time an event is raised.
>>
>>> The bottleneck may be some unrelated program that happens to be running.
>>
>> If this were true, I would expect it to affect both samples equally.
>>
>>> The bottleneck may be some unforeseen disk access, such as page
>>> swapping.
>>
>> As above.
>>
>>> The bottleneck may be any number of other things...
>>
>> I appreciate that you are illustrating the general point that the problem
>> might lie elsewhere, somewhere that we have not considered, but I have
>> attempted to make all things equal, so that the only differences in my
>> samples are down to the detail of the test that I am conducting.
>>
>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>> accurately identify where specifically the bottle neck is.
>>
>> I have had another look at the CLR Profiler and I can only say that I
>> understand now why it is free. There are many diverse requirements for
>> memory profiling, but as far as I can see none of them are intuitively
>> handled by the CLR Profiler.
>>
>>> As Charles initially stated "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." The "sometimes, for no
>>> apparent reason" would suggest to me that it is not specifically the RTF
>>> or the BeginInvoke, although it could be.
>>
>> Agreed, But it may be that because of the way the RTB is implemented
>> there is a lot of memory manipulation going on that impairs performance.
>>
>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>
>> Also agreed.
>>
>> My gut feeling is that the RTB is not the best tool for the job that I
>> started out with. That said, the job I started out with is probably quite
>> a stretch full-stop. I suspect that I should take more control over the
>> delivery of status to the user based on the amount of information I am
>> trying to deliver. I am inclined to believe that the fundamental flaw is
>> that I am trying to present too much information in a short space of
>> time, with controls that are not designed for that kind of performance. I
>> could probably write a more efficient control, but there would be a lot
>> of functionality to reproduce, and it may not be necessary if I modify
>> slightly my contact with the user.
>>
>> Charles
>>
>>
>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
>> news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>>> Cor & CMM,
>>>> This I can tell of course only now because we did not know that the
>>>> RTFbox was the bottleneck.
>>> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView
>>> is faster then the RTF Box, but that does not prove that the RTFBox is
>>> the bottle neck!
>>>
>>> The bottleneck may be the interop marshalling from .NET world to the
>>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>>> will have a problem as both are based on "native" Win32 controls.
>>>
>>> The bottleneck may be the GC!
>>>
>>> The bottleneck may actually be the way Charles' program is interacting
>>> with memory.
>>>
>>> The bottleneck may be some unrelated program that happens to be running.
>>>
>>> The bottleneck may be some unforseen disk access, such as page swapping.
>>>
>>> The bottleneck may be any number of other things...
>>>
>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>> accurately identify where specifically the bottle neck is.
>>>
>>> Or at the very least two methods & see which is faster. However I have
>>> seen where one method may be faster for small number and/or size of
>>> objects, suddenly becomes painfully slow for large number and/or size of
>>> objects...
>>>
>>> As Charles initially stated "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." The "sometimes, for no
>>> apparent reason" would suggest to me that it is not specifically the RTF
>>> or the BeginInvoke, although it could be.
>>>
>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>
>>> Just a thought
>>> Jay
>>>
>>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>>> Charles,
>>>>
>>>> It has not to do with the way I told or others told
>>>>
>>>> This has to do with the design.
>>>>
>>>> When you use 3 instead of 2 tiers than you can let your loading of your
>>>> RTFBox go smooth without any waiting in a seperated thread. Collect the
>>>> information for that in another tier as well in a seperated thread. And
>>>> let the worker tiers get the information for the last in as well
>>>> seperated threads.
>>>>
>>>> This I can tell of course only now because we did not know that the
>>>> RTFbox was the bottleneck.
>>>>
>>>> Describes this better what I mean?
>>>>
>>>> Cor
>>>>
>>>
>>>
>>
>>
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:udqQRWjMFHA.3320@TK2MSFTNGP15.phx.gbl...
> Jay
>
> I have been toying with trying a grid, now that I have moved away from the
> RTB, but I fear that whilst the performance of the ListView is excellent,
> I might sacrifice some of that performance by moving to a more complex
> control.
>
> The downside of abandoning the RTB is that I have lost the ability to save
> the information with its colour highlighting. I have tried writing each
> line, with colouring, to an invisible RTB at the end of the whole process
> so that I can use its SaveFile method to save the RTF, but it takes
> minutes to execute, so is not an option.
>
> I could serialise the ListView to an xml file, with attributes to indicate
> colour (or status, actually), and reload very quickly, but my user does
> not have anything to display it other than my program. RTF seemed the best
> way to include colouring so that it could be loaded by Word, for example,
> and viewed and printed easily.
>
> Isn't it always the way: one solves one problem often at the expense of
> creating another.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
> news:OcqtNCiMFHA.576@TK2MSFTNGP15.phx.gbl...
>> Charles,
>>> My gut feeling is that the RTB is not the best tool for the job that I
>>> started out with.
>> My gut feeling is the RTB is not the best tool for the job. However this
>> is from a presentation standpoint & not a performance standpoint!
>>
>> It sounds like you are displaying when a series of events occurred in a
>> process, a ListView (in Details mode) or a Grid sounds like a better fit.
>>
>>> I am inclined to believe that the fundamental flaw is that I am trying
>>> to present too much information in a short space of time,
>> Agreed
>>
>>> with controls that are not designed for that kind of performance.
>> Depending on how short the "short space of time" is, there may not be a
>> control worthy of the performance...
>>
>>
>> Just a thought
>> Jay
>>
>> "Charles Law" <bl***@nowhere.com> wrote in message
>> news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
>>> Hi Jay
>>>
>>> I am convinced that the RichTextBox is /a/ bottleneck.
>>>
>>>> The bottleneck may be the GC!
>>>
>>> Interestingly, I noticed that in my tests, there was a noticeable pause
>>> early in the updating of he RTB. It contained only a dozen lines, but I
>>> detected a half-second pause as the screen was updating. This was
>>> reproducible. There is every chance that this would re-occur later, and
>>> when the RTB is fuller, the delay could be longer.
>>>
>>>> The bottleneck may actually be the way Charles' program is interacting
>>>> with memory.
>>>
>>> In my real-world application this is true. But my samples are trivial.
>>> Object creation is minimal, but it is true that in the event sample, an
>>> EventArgs object is created every time an event is raised.
>>>
>>>> The bottleneck may be some unrelated program that happens to be
>>>> running.
>>>
>>> If this were true, I would expect it to affect both samples equally.
>>>
>>>> The bottleneck may be some unforeseen disk access, such as page
>>>> swapping.
>>>
>>> As above.
>>>
>>>> The bottleneck may be any number of other things...
>>>
>>> I appreciate that you are illustrating the general point that the
>>> problem might lie elsewhere, somewhere that we have not considered, but
>>> I have attempted to make all things equal, so that the only differences
>>> in my samples are down to the detail of the test that I am conducting.
>>>
>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>> accurately identify where specifically the bottle neck is.
>>>
>>> I have had another look at the CLR Profiler and I can only say that I
>>> understand now why it is free. There are many diverse requirements for
>>> memory profiling, but as far as I can see none of them are intuitively
>>> handled by the CLR Profiler.
>>>
>>>> As Charles initially stated "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." The "sometimes, for
>>>> no apparent reason" would suggest to me that it is not specifically the
>>>> RTF or the BeginInvoke, although it could be.
>>>
>>> Agreed, But it may be that because of the way the RTB is implemented
>>> there is a lot of memory manipulation going on that impairs performance.
>>>
>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>
>>> Also agreed.
>>>
>>> My gut feeling is that the RTB is not the best tool for the job that I
>>> started out with. That said, the job I started out with is probably
>>> quite a stretch full-stop. I suspect that I should take more control
>>> over the delivery of status to the user based on the amount of
>>> information I am trying to deliver. I am inclined to believe that the
>>> fundamental flaw is that I am trying to present too much information in
>>> a short space of time, with controls that are not designed for that kind
>>> of performance. I could probably write a more efficient control, but
>>> there would be a lot of functionality to reproduce, and it may not be
>>> necessary if I modify slightly my contact with the user.
>>>
>>> Charles
>>>
>>>
>>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in
>>> message news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>>>> Cor & CMM,
>>>>> This I can tell of course only now because we did not know that the
>>>>> RTFbox was the bottleneck.
>>>> I'm not convinced the bottleneck is the RTF box per se! Yes the
>>>> ListView is faster then the RTF Box, but that does not prove that the
>>>> RTFBox is the bottle neck!
>>>>
>>>> The bottleneck may be the interop marshalling from .NET world to the
>>>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>>>> will have a problem as both are based on "native" Win32 controls.
>>>>
>>>> The bottleneck may be the GC!
>>>>
>>>> The bottleneck may actually be the way Charles' program is interacting
>>>> with memory.
>>>>
>>>> The bottleneck may be some unrelated program that happens to be
>>>> running.
>>>>
>>>> The bottleneck may be some unforseen disk access, such as page
>>>> swapping.
>>>>
>>>> The bottleneck may be any number of other things...
>>>>
>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>> accurately identify where specifically the bottle neck is.
>>>>
>>>> Or at the very least two methods & see which is faster. However I have
>>>> seen where one method may be faster for small number and/or size of
>>>> objects, suddenly becomes painfully slow for large number and/or size
>>>> of objects...
>>>>
>>>> As Charles initially stated "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." The "sometimes, for
>>>> no apparent reason" would suggest to me that it is not specifically the
>>>> RTF or the BeginInvoke, although it could be.
>>>>
>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>>
>>>> Just a thought
>>>> Jay
>>>>
>>>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>>>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>>>> Charles,
>>>>>
>>>>> It has not to do with the way I told or others told
>>>>>
>>>>> This has to do with the design.
>>>>>
>>>>> When you use 3 instead of 2 tiers than you can let your loading of
>>>>> your RTFBox go smooth without any waiting in a seperated thread.
>>>>> Collect the information for that in another tier as well in a
>>>>> seperated thread. And let the worker tiers get the information for the
>>>>> last in as well seperated threads.
>>>>>
>>>>> This I can tell of course only now because we did not know that the
>>>>> RTFbox was the bottleneck.
>>>>>
>>>>> Describes this better what I mean?
>>>>>
>>>>> Cor
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:OcqtNCiMFHA.576@TK2MSFTNGP15.phx.gbl...
> Charles,
>> My gut feeling is that the RTB is not the best tool for the job that I
>> started out with.
> My gut feeling is the RTB is not the best tool for the job. However this
> is from a presentation standpoint & not a performance standpoint!
>
> It sounds like you are displaying when a series of events occurred in a
> process, a ListView (in Details mode) or a Grid sounds like a better fit.
>
>> I am inclined to believe that the fundamental flaw is that I am trying to
>> present too much information in a short space of time,
> Agreed
>
>> with controls that are not designed for that kind of performance.
> Depending on how short the "short space of time" is, there may not be a
> control worthy of the performance...
>
>
> Just a thought
> Jay
>
> "Charles Law" <bl***@nowhere.com> wrote in message
> news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
>> Hi Jay
>>
>> I am convinced that the RichTextBox is /a/ bottleneck.
>>
>>> The bottleneck may be the GC!
>>
>> Interestingly, I noticed that in my tests, there was a noticeable pause
>> early in the updating of he RTB. It contained only a dozen lines, but I
>> detected a half-second pause as the screen was updating. This was
>> reproducible. There is every chance that this would re-occur later, and
>> when the RTB is fuller, the delay could be longer.
>>
>>> The bottleneck may actually be the way Charles' program is interacting
>>> with memory.
>>
>> In my real-world application this is true. But my samples are trivial.
>> Object creation is minimal, but it is true that in the event sample, an
>> EventArgs object is created every time an event is raised.
>>
>>> The bottleneck may be some unrelated program that happens to be running.
>>
>> If this were true, I would expect it to affect both samples equally.
>>
>>> The bottleneck may be some unforeseen disk access, such as page
>>> swapping.
>>
>> As above.
>>
>>> The bottleneck may be any number of other things...
>>
>> I appreciate that you are illustrating the general point that the problem
>> might lie elsewhere, somewhere that we have not considered, but I have
>> attempted to make all things equal, so that the only differences in my
>> samples are down to the detail of the test that I am conducting.
>>
>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>> accurately identify where specifically the bottle neck is.
>>
>> I have had another look at the CLR Profiler and I can only say that I
>> understand now why it is free. There are many diverse requirements for
>> memory profiling, but as far as I can see none of them are intuitively
>> handled by the CLR Profiler.
>>
>>> As Charles initially stated "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." The "sometimes, for no
>>> apparent reason" would suggest to me that it is not specifically the RTF
>>> or the BeginInvoke, although it could be.
>>
>> Agreed, But it may be that because of the way the RTB is implemented
>> there is a lot of memory manipulation going on that impairs performance.
>>
>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>
>> Also agreed.
>>
>> My gut feeling is that the RTB is not the best tool for the job that I
>> started out with. That said, the job I started out with is probably quite
>> a stretch full-stop. I suspect that I should take more control over the
>> delivery of status to the user based on the amount of information I am
>> trying to deliver. I am inclined to believe that the fundamental flaw is
>> that I am trying to present too much information in a short space of
>> time, with controls that are not designed for that kind of performance. I
>> could probably write a more efficient control, but there would be a lot
>> of functionality to reproduce, and it may not be necessary if I modify
>> slightly my contact with the user.
>>
>> Charles
>>
>>
>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
>> news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>>> Cor & CMM,
>>>> This I can tell of course only now because we did not know that the
>>>> RTFbox was the bottleneck.
>>> I'm not convinced the bottleneck is the RTF box per se! Yes the ListView
>>> is faster then the RTF Box, but that does not prove that the RTFBox is
>>> the bottle neck!
>>>
>>> The bottleneck may be the interop marshalling from .NET world to the
>>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>>> will have a problem as both are based on "native" Win32 controls.
>>>
>>> The bottleneck may be the GC!
>>>
>>> The bottleneck may actually be the way Charles' program is interacting
>>> with memory.
>>>
>>> The bottleneck may be some unrelated program that happens to be running.
>>>
>>> The bottleneck may be some unforseen disk access, such as page swapping.
>>>
>>> The bottleneck may be any number of other things...
>>>
>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>> accurately identify where specifically the bottle neck is.
>>>
>>> Or at the very least two methods & see which is faster. However I have
>>> seen where one method may be faster for small number and/or size of
>>> objects, suddenly becomes painfully slow for large number and/or size of
>>> objects...
>>>
>>> As Charles initially stated "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." The "sometimes, for no
>>> apparent reason" would suggest to me that it is not specifically the RTF
>>> or the BeginInvoke, although it could be.
>>>
>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>
>>> Just a thought
>>> Jay
>>>
>>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>>> Charles,
>>>>
>>>> It has not to do with the way I told or others told
>>>>
>>>> This has to do with the design.
>>>>
>>>> When you use 3 instead of 2 tiers than you can let your loading of your
>>>> RTFBox go smooth without any waiting in a seperated thread. Collect the
>>>> information for that in another tier as well in a seperated thread. And
>>>> let the worker tiers get the information for the last in as well
>>>> seperated threads.
>>>>
>>>> This I can tell of course only now because we did not know that the
>>>> RTFbox was the bottleneck.
>>>>
>>>> Describes this better what I mean?
>>>>
>>>> Cor
>>>>
>>>
>>>
>>
>>
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:udqQRWjMFHA.3320@TK2MSFTNGP15.phx.gbl...
> Jay
>
> I have been toying with trying a grid, now that I have moved away from the
> RTB, but I fear that whilst the performance of the ListView is excellent,
> I might sacrifice some of that performance by moving to a more complex
> control.
>
> The downside of abandoning the RTB is that I have lost the ability to save
> the information with its colour highlighting. I have tried writing each
> line, with colouring, to an invisible RTB at the end of the whole process
> so that I can use its SaveFile method to save the RTF, but it takes
> minutes to execute, so is not an option.
>
> I could serialise the ListView to an xml file, with attributes to indicate
> colour (or status, actually), and reload very quickly, but my user does
> not have anything to display it other than my program. RTF seemed the best
> way to include colouring so that it could be loaded by Word, for example,
> and viewed and printed easily.
>
> Isn't it always the way: one solves one problem often at the expense of
> creating another.
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
> news:OcqtNCiMFHA.576@TK2MSFTNGP15.phx.gbl...
>> Charles,
>>> My gut feeling is that the RTB is not the best tool for the job that I
>>> started out with.
>> My gut feeling is the RTB is not the best tool for the job. However this
>> is from a presentation standpoint & not a performance standpoint!
>>
>> It sounds like you are displaying when a series of events occurred in a
>> process, a ListView (in Details mode) or a Grid sounds like a better fit.
>>
>>> I am inclined to believe that the fundamental flaw is that I am trying
>>> to present too much information in a short space of time,
>> Agreed
>>
>>> with controls that are not designed for that kind of performance.
>> Depending on how short the "short space of time" is, there may not be a
>> control worthy of the performance...
>>
>>
>> Just a thought
>> Jay
>>
>> "Charles Law" <bl***@nowhere.com> wrote in message
>> news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
>>> Hi Jay
>>>
>>> I am convinced that the RichTextBox is /a/ bottleneck.
>>>
>>>> The bottleneck may be the GC!
>>>
>>> Interestingly, I noticed that in my tests, there was a noticeable pause
>>> early in the updating of he RTB. It contained only a dozen lines, but I
>>> detected a half-second pause as the screen was updating. This was
>>> reproducible. There is every chance that this would re-occur later, and
>>> when the RTB is fuller, the delay could be longer.
>>>
>>>> The bottleneck may actually be the way Charles' program is interacting
>>>> with memory.
>>>
>>> In my real-world application this is true. But my samples are trivial.
>>> Object creation is minimal, but it is true that in the event sample, an
>>> EventArgs object is created every time an event is raised.
>>>
>>>> The bottleneck may be some unrelated program that happens to be
>>>> running.
>>>
>>> If this were true, I would expect it to affect both samples equally.
>>>
>>>> The bottleneck may be some unforeseen disk access, such as page
>>>> swapping.
>>>
>>> As above.
>>>
>>>> The bottleneck may be any number of other things...
>>>
>>> I appreciate that you are illustrating the general point that the
>>> problem might lie elsewhere, somewhere that we have not considered, but
>>> I have attempted to make all things equal, so that the only differences
>>> in my samples are down to the detail of the test that I am conducting.
>>>
>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>> accurately identify where specifically the bottle neck is.
>>>
>>> I have had another look at the CLR Profiler and I can only say that I
>>> understand now why it is free. There are many diverse requirements for
>>> memory profiling, but as far as I can see none of them are intuitively
>>> handled by the CLR Profiler.
>>>
>>>> As Charles initially stated "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." The "sometimes, for
>>>> no apparent reason" would suggest to me that it is not specifically the
>>>> RTF or the BeginInvoke, although it could be.
>>>
>>> Agreed, But it may be that because of the way the RTB is implemented
>>> there is a lot of memory manipulation going on that impairs performance.
>>>
>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>
>>> Also agreed.
>>>
>>> My gut feeling is that the RTB is not the best tool for the job that I
>>> started out with. That said, the job I started out with is probably
>>> quite a stretch full-stop. I suspect that I should take more control
>>> over the delivery of status to the user based on the amount of
>>> information I am trying to deliver. I am inclined to believe that the
>>> fundamental flaw is that I am trying to present too much information in
>>> a short space of time, with controls that are not designed for that kind
>>> of performance. I could probably write a more efficient control, but
>>> there would be a lot of functionality to reproduce, and it may not be
>>> necessary if I modify slightly my contact with the user.
>>>
>>> Charles
>>>
>>>
>>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in
>>> message news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>>>> Cor & CMM,
>>>>> This I can tell of course only now because we did not know that the
>>>>> RTFbox was the bottleneck.
>>>> I'm not convinced the bottleneck is the RTF box per se! Yes the
>>>> ListView is faster then the RTF Box, but that does not prove that the
>>>> RTFBox is the bottle neck!
>>>>
>>>> The bottleneck may be the interop marshalling from .NET world to the
>>>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>>>> will have a problem as both are based on "native" Win32 controls.
>>>>
>>>> The bottleneck may be the GC!
>>>>
>>>> The bottleneck may actually be the way Charles' program is interacting
>>>> with memory.
>>>>
>>>> The bottleneck may be some unrelated program that happens to be
>>>> running.
>>>>
>>>> The bottleneck may be some unforseen disk access, such as page
>>>> swapping.
>>>>
>>>> The bottleneck may be any number of other things...
>>>>
>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>> accurately identify where specifically the bottle neck is.
>>>>
>>>> Or at the very least two methods & see which is faster. However I have
>>>> seen where one method may be faster for small number and/or size of
>>>> objects, suddenly becomes painfully slow for large number and/or size
>>>> of objects...
>>>>
>>>> As Charles initially stated "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." The "sometimes, for
>>>> no apparent reason" would suggest to me that it is not specifically the
>>>> RTF or the BeginInvoke, although it could be.
>>>>
>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>>
>>>> Just a thought
>>>> Jay
>>>>
>>>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>>>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>>>> Charles,
>>>>>
>>>>> It has not to do with the way I told or others told
>>>>>
>>>>> This has to do with the design.
>>>>>
>>>>> When you use 3 instead of 2 tiers than you can let your loading of
>>>>> your RTFBox go smooth without any waiting in a seperated thread.
>>>>> Collect the information for that in another tier as well in a
>>>>> seperated thread. And let the worker tiers get the information for the
>>>>> last in as well seperated threads.
>>>>>
>>>>> This I can tell of course only now because we did not know that the
>>>>> RTFbox was the bottleneck.
>>>>>
>>>>> Describes this better what I mean?
>>>>>
>>>>> Cor
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:%23Je%23knoMFHA.2704@TK2MSFTNGP15.phx.gbl...
> Charles,
> I'm concerned you are treating symptoms rather then treating the illness
> itself. :-|
>
> I would half expect DataGrid to be slower then ListView just by the very
> nature of the controls.
>
> 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...
>
> Hope this helps
> Jay
>
> "Charles Law" <bl***@nowhere.com> wrote in message
> news:udqQRWjMFHA.3320@TK2MSFTNGP15.phx.gbl...
>> Jay
>>
>> I have been toying with trying a grid, now that I have moved away from
>> the RTB, but I fear that whilst the performance of the ListView is
>> excellent, I might sacrifice some of that performance by moving to a more
>> complex control.
>>
>> The downside of abandoning the RTB is that I have lost the ability to
>> save the information with its colour highlighting. I have tried writing
>> each line, with colouring, to an invisible RTB at the end of the whole
>> process so that I can use its SaveFile method to save the RTF, but it
>> takes minutes to execute, so is not an option.
>>
>> I could serialise the ListView to an xml file, with attributes to
>> indicate colour (or status, actually), and reload very quickly, but my
>> user does not have anything to display it other than my program. RTF
>> seemed the best way to include colouring so that it could be loaded by
>> Word, for example, and viewed and printed easily.
>>
>> Isn't it always the way: one solves one problem often at the expense of
>> creating another.
>>
>> Charles
>>
>>
>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
>> news:OcqtNCiMFHA.576@TK2MSFTNGP15.phx.gbl...
>>> Charles,
>>>> My gut feeling is that the RTB is not the best tool for the job that I
>>>> started out with.
>>> My gut feeling is the RTB is not the best tool for the job. However this
>>> is from a presentation standpoint & not a performance standpoint!
>>>
>>> It sounds like you are displaying when a series of events occurred in a
>>> process, a ListView (in Details mode) or a Grid sounds like a better
>>> fit.
>>>
>>>> I am inclined to believe that the fundamental flaw is that I am trying
>>>> to present too much information in a short space of time,
>>> Agreed
>>>
>>>> with controls that are not designed for that kind of performance.
>>> Depending on how short the "short space of time" is, there may not be a
>>> control worthy of the performance...
>>>
>>>
>>> Just a thought
>>> Jay
>>>
>>> "Charles Law" <bl***@nowhere.com> wrote in message
>>> news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
>>>> Hi Jay
>>>>
>>>> I am convinced that the RichTextBox is /a/ bottleneck.
>>>>
>>>>> The bottleneck may be the GC!
>>>>
>>>> Interestingly, I noticed that in my tests, there was a noticeable pause
>>>> early in the updating of he RTB. It contained only a dozen lines, but I
>>>> detected a half-second pause as the screen was updating. This was
>>>> reproducible. There is every chance that this would re-occur later, and
>>>> when the RTB is fuller, the delay could be longer.
>>>>
>>>>> The bottleneck may actually be the way Charles' program is interacting
>>>>> with memory.
>>>>
>>>> In my real-world application this is true. But my samples are trivial.
>>>> Object creation is minimal, but it is true that in the event sample, an
>>>> EventArgs object is created every time an event is raised.
>>>>
>>>>> The bottleneck may be some unrelated program that happens to be
>>>>> running.
>>>>
>>>> If this were true, I would expect it to affect both samples equally.
>>>>
>>>>> The bottleneck may be some unforeseen disk access, such as page
>>>>> swapping.
>>>>
>>>> As above.
>>>>
>>>>> The bottleneck may be any number of other things...
>>>>
>>>> I appreciate that you are illustrating the general point that the
>>>> problem might lie elsewhere, somewhere that we have not considered, but
>>>> I have attempted to make all things equal, so that the only differences
>>>> in my samples are down to the detail of the test that I am conducting.
>>>>
>>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>>> accurately identify where specifically the bottle neck is.
>>>>
>>>> I have had another look at the CLR Profiler and I can only say that I
>>>> understand now why it is free. There are many diverse requirements for
>>>> memory profiling, but as far as I can see none of them are intuitively
>>>> handled by the CLR Profiler.
>>>>
>>>>> As Charles initially stated "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." The "sometimes, for
>>>>> no apparent reason" would suggest to me that it is not specifically
>>>>> the RTF or the BeginInvoke, although it could be.
>>>>
>>>> Agreed, But it may be that because of the way the RTB is implemented
>>>> there is a lot of memory manipulation going on that impairs
>>>> performance.
>>>>
>>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>>
>>>> Also agreed.
>>>>
>>>> My gut feeling is that the RTB is not the best tool for the job that I
>>>> started out with. That said, the job I started out with is probably
>>>> quite a stretch full-stop. I suspect that I should take more control
>>>> over the delivery of status to the user based on the amount of
>>>> information I am trying to deliver. I am inclined to believe that the
>>>> fundamental flaw is that I am trying to present too much information in
>>>> a short space of time, with controls that are not designed for that
>>>> kind of performance. I could probably write a more efficient control,
>>>> but there would be a lot of functionality to reproduce, and it may not
>>>> be necessary if I modify slightly my contact with the user.
>>>>
>>>> Charles
>>>>
>>>>
>>>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in
>>>> message news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>>>>> Cor & CMM,
>>>>>> This I can tell of course only now because we did not know that the
>>>>>> RTFbox was the bottleneck.
>>>>> I'm not convinced the bottleneck is the RTF box per se! Yes the
>>>>> ListView is faster then the RTF Box, but that does not prove that the
>>>>> RTFBox is the bottle neck!
>>>>>
>>>>> The bottleneck may be the interop marshalling from .NET world to the
>>>>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>>>>> will have a problem as both are based on "native" Win32 controls.
>>>>>
>>>>> The bottleneck may be the GC!
>>>>>
>>>>> The bottleneck may actually be the way Charles' program is interacting
>>>>> with memory.
>>>>>
>>>>> The bottleneck may be some unrelated program that happens to be
>>>>> running.
>>>>>
>>>>> The bottleneck may be some unforseen disk access, such as page
>>>>> swapping.
>>>>>
>>>>> The bottleneck may be any number of other things...
>>>>>
>>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>>> accurately identify where specifically the bottle neck is.
>>>>>
>>>>> Or at the very least two methods & see which is faster. However I have
>>>>> seen where one method may be faster for small number and/or size of
>>>>> objects, suddenly becomes painfully slow for large number and/or size
>>>>> of objects...
>>>>>
>>>>> As Charles initially stated "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." The "sometimes, for
>>>>> no apparent reason" would suggest to me that it is not specifically
>>>>> the RTF or the BeginInvoke, although it could be.
>>>>>
>>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>>>
>>>>> Just a thought
>>>>> Jay
>>>>>
>>>>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>>>>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>>>>> Charles,
>>>>>>
>>>>>> It has not to do with the way I told or others told
>>>>>>
>>>>>> This has to do with the design.
>>>>>>
>>>>>> When you use 3 instead of 2 tiers than you can let your loading of
>>>>>> your RTFBox go smooth without any waiting in a seperated thread.
>>>>>> Collect the information for that in another tier as well in a
>>>>>> seperated thread. And let the worker tiers get the information for
>>>>>> the last in as well seperated threads.
>>>>>>
>>>>>> This I can tell of course only now because we did not know that the
>>>>>> RTFbox was the bottleneck.
>>>>>>
>>>>>> Describes this better what I mean?
>>>>>>
>>>>>> Cor
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:O$p$gQrMFHA.1500@TK2MSFTNGP09.phx.gbl...
>
> Jay
>
>> I'm concerned you are treating symptoms rather then treating the illness
>> itself. :-|
>
> 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.
>
>> 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...
>
> 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
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:%23Je%23knoMFHA.2704@TK2MSFTNGP15.phx.gbl...
> Charles,
> I'm concerned you are treating symptoms rather then treating the illness
> itself. :-|
>
> I would half expect DataGrid to be slower then ListView just by the very
> nature of the controls.
>
> 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...
>
> Hope this helps
> Jay
>
> "Charles Law" <bl***@nowhere.com> wrote in message
> news:udqQRWjMFHA.3320@TK2MSFTNGP15.phx.gbl...
>> Jay
>>
>> I have been toying with trying a grid, now that I have moved away from
>> the RTB, but I fear that whilst the performance of the ListView is
>> excellent, I might sacrifice some of that performance by moving to a more
>> complex control.
>>
>> The downside of abandoning the RTB is that I have lost the ability to
>> save the information with its colour highlighting. I have tried writing
>> each line, with colouring, to an invisible RTB at the end of the whole
>> process so that I can use its SaveFile method to save the RTF, but it
>> takes minutes to execute, so is not an option.
>>
>> I could serialise the ListView to an xml file, with attributes to
>> indicate colour (or status, actually), and reload very quickly, but my
>> user does not have anything to display it other than my program. RTF
>> seemed the best way to include colouring so that it could be loaded by
>> Word, for example, and viewed and printed easily.
>>
>> Isn't it always the way: one solves one problem often at the expense of
>> creating another.
>>
>> Charles
>>
>>
>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
>> news:OcqtNCiMFHA.576@TK2MSFTNGP15.phx.gbl...
>>> Charles,
>>>> My gut feeling is that the RTB is not the best tool for the job that I
>>>> started out with.
>>> My gut feeling is the RTB is not the best tool for the job. However this
>>> is from a presentation standpoint & not a performance standpoint!
>>>
>>> It sounds like you are displaying when a series of events occurred in a
>>> process, a ListView (in Details mode) or a Grid sounds like a better
>>> fit.
>>>
>>>> I am inclined to believe that the fundamental flaw is that I am trying
>>>> to present too much information in a short space of time,
>>> Agreed
>>>
>>>> with controls that are not designed for that kind of performance.
>>> Depending on how short the "short space of time" is, there may not be a
>>> control worthy of the performance...
>>>
>>>
>>> Just a thought
>>> Jay
>>>
>>> "Charles Law" <bl***@nowhere.com> wrote in message
>>> news:%23ti1YxZMFHA.2680@TK2MSFTNGP09.phx.gbl...
>>>> Hi Jay
>>>>
>>>> I am convinced that the RichTextBox is /a/ bottleneck.
>>>>
>>>>> The bottleneck may be the GC!
>>>>
>>>> Interestingly, I noticed that in my tests, there was a noticeable pause
>>>> early in the updating of he RTB. It contained only a dozen lines, but I
>>>> detected a half-second pause as the screen was updating. This was
>>>> reproducible. There is every chance that this would re-occur later, and
>>>> when the RTB is fuller, the delay could be longer.
>>>>
>>>>> The bottleneck may actually be the way Charles' program is interacting
>>>>> with memory.
>>>>
>>>> In my real-world application this is true. But my samples are trivial.
>>>> Object creation is minimal, but it is true that in the event sample, an
>>>> EventArgs object is created every time an event is raised.
>>>>
>>>>> The bottleneck may be some unrelated program that happens to be
>>>>> running.
>>>>
>>>> If this were true, I would expect it to affect both samples equally.
>>>>
>>>>> The bottleneck may be some unforeseen disk access, such as page
>>>>> swapping.
>>>>
>>>> As above.
>>>>
>>>>> The bottleneck may be any number of other things...
>>>>
>>>> I appreciate that you are illustrating the general point that the
>>>> problem might lie elsewhere, somewhere that we have not considered, but
>>>> I have attempted to make all things equal, so that the only differences
>>>> in my samples are down to the detail of the test that I am conducting.
>>>>
>>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>>> accurately identify where specifically the bottle neck is.
>>>>
>>>> I have had another look at the CLR Profiler and I can only say that I
>>>> understand now why it is free. There are many diverse requirements for
>>>> memory profiling, but as far as I can see none of them are intuitively
>>>> handled by the CLR Profiler.
>>>>
>>>>> As Charles initially stated "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." The "sometimes, for
>>>>> no apparent reason" would suggest to me that it is not specifically
>>>>> the RTF or the BeginInvoke, although it could be.
>>>>
>>>> Agreed, But it may be that because of the way the RTB is implemented
>>>> there is a lot of memory manipulation going on that impairs
>>>> performance.
>>>>
>>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>>
>>>> Also agreed.
>>>>
>>>> My gut feeling is that the RTB is not the best tool for the job that I
>>>> started out with. That said, the job I started out with is probably
>>>> quite a stretch full-stop. I suspect that I should take more control
>>>> over the delivery of status to the user based on the amount of
>>>> information I am trying to deliver. I am inclined to believe that the
>>>> fundamental flaw is that I am trying to present too much information in
>>>> a short space of time, with controls that are not designed for that
>>>> kind of performance. I could probably write a more efficient control,
>>>> but there would be a lot of functionality to reproduce, and it may not
>>>> be necessary if I modify slightly my contact with the user.
>>>>
>>>> Charles
>>>>
>>>>
>>>> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in
>>>> message news:%23JzSgSXMFHA.3928@TK2MSFTNGP09.phx.gbl...
>>>>> Cor & CMM,
>>>>>> This I can tell of course only now because we did not know that the
>>>>>> RTFbox was the bottleneck.
>>>>> I'm not convinced the bottleneck is the RTF box per se! Yes the
>>>>> ListView is faster then the RTF Box, but that does not prove that the
>>>>> RTFBox is the bottle neck!
>>>>>
>>>>> The bottleneck may be the interop marshalling from .NET world to the
>>>>> Win32 RTF Textbox world. In which case both the RTFBox & the ListView
>>>>> will have a problem as both are based on "native" Win32 controls.
>>>>>
>>>>> The bottleneck may be the GC!
>>>>>
>>>>> The bottleneck may actually be the way Charles' program is interacting
>>>>> with memory.
>>>>>
>>>>> The bottleneck may be some unrelated program that happens to be
>>>>> running.
>>>>>
>>>>> The bottleneck may be some unforseen disk access, such as page
>>>>> swapping.
>>>>>
>>>>> The bottleneck may be any number of other things...
>>>>>
>>>>> Hence my suggestion to use CLR Profiler & other tools to try to
>>>>> accurately identify where specifically the bottle neck is.
>>>>>
>>>>> Or at the very least two methods & see which is faster. However I have
>>>>> seen where one method may be faster for small number and/or size of
>>>>> objects, suddenly becomes painfully slow for large number and/or size
>>>>> of objects...
>>>>>
>>>>> As Charles initially stated "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." The "sometimes, for
>>>>> no apparent reason" would suggest to me that it is not specifically
>>>>> the RTF or the BeginInvoke, although it could be.
>>>>>
>>>>> In other words BeginInvoke & the RTF Box are both still suspects,
>>>>> however the jury (CLR Profiler) has not convicted them of any crime.
>>>>>
>>>>> Just a thought
>>>>> Jay
>>>>>
>>>>> "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
>>>>> news:enx36kVMFHA.2648@TK2MSFTNGP14.phx.gbl...
>>>>>> Charles,
>>>>>>
>>>>>> It has not to do with the way I told or others told
>>>>>>
>>>>>> This has to do with the design.
>>>>>>
>>>>>> When you use 3 instead of 2 tiers than you can let your loading of
>>>>>> your RTFBox go smooth without any waiting in a seperated thread.
>>>>>> Collect the information for that in another tier as well in a
>>>>>> seperated thread. And let the worker tiers get the information for
>>>>>> the last in as well seperated threads.
>>>>>>
>>>>>> This I can tell of course only now because we did not know that the
>>>>>> RTFbox was the bottleneck.
>>>>>>
>>>>>> Describes this better what I mean?
>>>>>>
>>>>>> Cor
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:O$p$gQrMFHA.1500@TK2MSFTNGP09.phx.gbl...
>
> Jay
>
>> I'm concerned you are treating symptoms rather then treating the illness
>> itself. :-|
>
> 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.
>
>> 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...
>
> 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
>
>

"Jay B. Harlow [MVP - Outlook]" wrote:

> Charles,
> >> I'm concerned you are treating symptoms rather then treating the illness
> >> itself. :-|
> >
> > I wasn't aware that I was. Surely the illness is displaying too much data,
>
> 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" <bl***@nowhere.com> wrote in message
> news:O$p$gQrMFHA.1500@TK2MSFTNGP09.phx.gbl...
> >
> > Jay
> >
> >> I'm concerned you are treating symptoms rather then treating the illness
> >> itself. :-|
> >
> > 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.
> >
> >> 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...
> >
> > 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
> >
> >
> <<snip>>
>
>
>

"Jay B. Harlow [MVP - Outlook]" wrote:

> Charles,
> >> I'm concerned you are treating symptoms rather then treating the illness
> >> itself. :-|
> >
> > I wasn't aware that I was. Surely the illness is displaying too much data,
>
> 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" <bl***@nowhere.com> wrote in message
> news:O$p$gQrMFHA.1500@TK2MSFTNGP09.phx.gbl...
> >
> > Jay
> >
> >> I'm concerned you are treating symptoms rather then treating the illness
> >> itself. :-|
> >
> > 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.
> >
> >> 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...
> >
> > 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
> >
> >
> <<snip>>
>
>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:up3j6XwMFHA.244@tk2msftngp13.phx.gbl...
> Charles,
>>> I'm concerned you are treating symptoms rather then treating the illness
>>> itself. :-|
>>
>> I wasn't aware that I was. Surely the illness is displaying too much
>> data,
>
> 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" <bl***@nowhere.com> wrote in message
> news:O$p$gQrMFHA.1500@TK2MSFTNGP09.phx.gbl...
>>
>> Jay
>>
>>> I'm concerned you are treating symptoms rather then treating the illness
>>> itself. :-|
>>
>> 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.
>>
>>> 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...
>>
>> 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
>>
>>
> <<snip>>
>

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@msn.com> wrote in message
news:up3j6XwMFHA.244@tk2msftngp13.phx.gbl...
> Charles,
>>> I'm concerned you are treating symptoms rather then treating the illness
>>> itself. :-|
>>
>> I wasn't aware that I was. Surely the illness is displaying too much
>> data,
>
> 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" <bl***@nowhere.com> wrote in message
> news:O$p$gQrMFHA.1500@TK2MSFTNGP09.phx.gbl...
>>
>> Jay
>>
>>> I'm concerned you are treating symptoms rather then treating the illness
>>> itself. :-|
>>
>> 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.
>>
>>> 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...
>>
>> 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
>>
>>
> <<snip>>
>