Changing richtext to bold w/o selecting text first

Howdie.
I used to have a solution to this, but for some reason have lost the links and my code for this, and no posts I have seen really answer this question.
The standard approach given, is that you select the text FIRST, then apply properties such as Text.SelBold = True to set the selection to bold. The problem with this is that my program is sending text to a Rich Text Box, and it must be formatted for bold BEFORE it gets to the text box, then, after it is printed, the following text after that needs to be changed back to normal weight. The documentation seems to suggest that using .selbold will work for anything after the cursor but this isn't working...it has no effect at all. Is it because I don't have a physical cursor present in the textbox?

Thanks for any replies.
treddie

Found it! Geezzzz!
I forgot to save the code I had written years ago as a stand alone snippet. I just remembered what program I had written it into, and NOW have extracted it out for posterity. It actually does use the SEL methods, but fools the textbox into thinking it is receiving text from the keyboard.

For anyone having the same problem, here is the code. It uses the SendKeys method to get text to the textbox as if it was typed in at the keyboard:
1. Build a RichText Box, and two buttons called "Go_cmd" and "Quit_cmd".
2. Copy the following vb6 code into the form:

Code:

---

Dim TestText_str As String
Dim target_str As String
Dim Send_str As String


Private Sub form_load()
'This program formats different sections of a Rich Text Box's text to different attributes, as it is being "typed" in
'by the program.  The SendKeys method sends text to a Rich Text Box as if it was typed in at keyboard by user.

End Sub



Private Sub Go_cmd_Click()
  RichTextBox.Text = ""
 
  Call HeaderPRINT
  Call PointLinePRINT
  Call FollowupPRINT
 
  'If at this point you want to use another .SetFocus property, precede it with "DoEvents",
  'so that the RichTextBox ops can finish up.  Otherwise the contents of the SendKeys buffer
  'gets misdirected to the new control.  This can cause weird results.  For instance, if the
  'new control is a command button instead of another textbox, the contents of the buffer
  'will keep "clicking" the command button in a continuous loop, almost as if SendKeys is
  'constantly querying the button to accept data.  If the command button is designed to quit
  'the app, SendKeys will do that, because it "clicked" the button, itself:
  DoEvents
  Quit_cmd.SetFocus
 
  'It is perhaps wiser simply to place a DoEvents statement at the end of each print text call.
  'That way, you know that all the contents of the SendKeys buffer have been properly sent to
  'the correct destination, and you don't have to worry about unsent info from then on, later on
  'in code.  This has been implemented in this program.  Therefore, the DoEvents statement directly
  'above this paragraph can be removed.
 
End Sub
 


Public Sub HeaderPRINT()
  'WARNING!!!  This line can conflict with other instances of SetFocus, and may cause weird results.
  'But ideally, every SendKeys statement (or batch of statements) should be preceded by "Show" and
  'the .SetFocus property for the corresponding textbox to make sure SendKeys is sending to the correct
  'control:
  Show
  RichTextBox.SetFocus
 
  Send_str = "_______________________________________________"
  SendKeys Send_str, False

  Send_str = vbLf
  SendKeys Send_str, False
 
  Send_str = "_______________________________________________"
  SendKeys Send_str, False

  Send_str = vbLf
  SendKeys Send_str, False
 
  Send_str = vbLf
  SendKeys Send_str, False

  'The DoEvents line MUST be placed here.  What happens is that SendKeys statement, above,
  'apparantly sends the text to a buffer, but it does not register as being present in the
  'text box until the program idles, allowing the system to THEN update the text box.
  'DoEvents short circuits this by allowing the text box to update immediately.
  'Even worse, it APPEARS that the SendKeys buffer cannot survive a Break command; it will
  'delete the text.  If you place a breakpoint at the DoEvents line, the action clears the
  'SendKeys buffer, so that when stepping through the code, when you get to any code that
  'accesses the text ammended by SendKeys, you find that the buffer contents do not register
  'as having been added to the text length.  May not be a vb6 bug, but might as well be.
  'In addition, later on, if you want to use another .SetFocus property, you want to make sure
  'that any SendKeys statements (or batch of successive SendKeys statements) have been immediately
  'followed with "DoEvents", so that the RichTextBox ops can finish up for that batch.  Otherwise the
  'contents of the SendKeys buffer gets misdirected to the new control.  This can cause weird results.
  'For instance, if the new control is a command button instead of another textbox, the contents of
  'the buffer will keep "clicking" the command button in a continuous loop, almost as if SendKeys is
  'constantly querying the button to accept data.  If the command button is designed to quit
  'the app, SendKeys will do that, because it "clicked" the button, itself.
  'So it is perhaps wisest to simply place a DoEvents statement at the end of each batch of SendKeys
  'statements.  That way, you know that all the contents of the SendKeys buffer have been properly sent
  'to the correct destination, and you don't have to worry about unsent info from then on, later on
  'in code.
  DoEvents

End Sub



Public Sub PointLinePRINT()
  'WARNING!!!  This line can conflict with other instances of SetFocus, and may cause weird results.
  'But ideally, every SendKeys statement (or batch of statements) should be preceded by "Show" and
  'the .SetFocus property for the corresponding textbox:
  Show
  RichTextBox.SetFocus
 
  'Do not put a vblf at end of string when using call to (FormatString).  The way
  'it is now written, (FormatString) will mess up the count of TRUE characters
  'in the string when it comes time to change text formatting  If you MUST include
  'it, then the "true" length of (target_str) will be Len(target_str) + 1:
  Send_str = "POINT " + " 12" + ":"    '+ vbLf
  SendKeys Send_str, False
  target_str = Send_str
 
  'The DoEvents line MUST be placed here.  What happens is that SendKeys apparantly
  'sends the text to a buffer, but it does not register as being present in the
  'text box until the program idles, allowing the system to THEN update the text box.
  'Therefore, the statement, "Len(RichTextBox.Text)" in the call to (FormatString),
  'will not register the updated length until the system is allowed to update the
  'text box. DoEvents short circuits this by allowing the text box to update immediately.
  'Even worse, it APPEARS that the SendKeys buffer cannot survive a Break command; it will
  'delete the text.  If you place a breakpoint at the DoEvents line, the action clears the
  'SendKeys buffer, so that when stepping through the code, when you get to the
  '"Len(RichTextBox.Text)" line, you find that the buffer contents do not register as having
  'been added to the text length.  May not be a vb6 bug, but might as well be.
  DoEvents
  Call FormatString

  Send_str = vbLf
  SendKeys Send_str, False
 
  DoEvents

End Sub



Public Sub FormatString()

  If Len(RichTextBox.Text) - Len(target_str) < 0 Then Exit Sub    'Invalid answer when < 0
 
  RichTextBox.SelStart = Len(RichTextBox.Text) - Len(target_str) ' Set selection start
  RichTextBox.SelLength = Len(target_str)
     
  RichTextBox.SelBold = True
  RichTextBox.SelColor = vbRed
  RichTextBox.SelStart = Len(RichTextBox.Text)
  RichTextBox.SelLength = 0
  RichTextBox.SelBold = False
  RichTextBox.SelColor = vbBlack

End Sub



Public Sub FollowupPRINT()
  'WARNING!!!  This line can conflict with other instances of SetFocus, and may cause weird results.
  'But ideally, every SendKeys statement (or batch of statements) should be preceded by "Show" and
  'the .SetFocus property for the corresponding textbox:
  Show
  RichTextBox.SetFocus
 
  'This line destroys the prior formatting:
  '  RichTextBox.Text = RichTextBox.Text + vbLf + "end of test." + vbLf
  'Must always use SendKeys method to preserve previous multiple-formatting in a textbox,
  'as well as keep present cursor position intact:
  Send_str = "end of test." + vbLf
  SendKeys Send_str, False
 
  'The DoEvents line MUST be placed here.  What happens is that SendKeys statement, above,
  'apparantly sends the text to a buffer, but it does not register as being present in the
  'text box until the program idles, allowing the system to THEN update the text box.
  'DoEvents short circuits this by allowing the text box to update immediately.
  'Even worse, it APPEARS that the SendKeys buffer cannot survive a Break command; it will
  'delete the text.  If you place a breakpoint at the DoEvents line, the action clears the
  'SendKeys buffer, so that when stepping through the code, when you get to any code that
  'accesses the text ammended by SendKeys, you find that the buffer contents do not register
  'as having been added to the text length.  May not be a vb6 bug, but might as well be.
  'In addition, later on, if you want to use another .SetFocus property, you want to make sure
  'that any SendKeys statements (or batch of successive SendKeys statements) have been immediately
  'followed with "DoEvents", so that the RichTextBox ops can finish up for that batch.  Otherwise the
  'contents of the SendKeys buffer gets misdirected to the new control.  This can cause weird results.
  'For instance, if the new control is a command button instead of another textbox, the contents of
  'the buffer will keep "clicking" the command button in a continuous loop, almost as if SendKeys is
  'constantly querying the button to accept data.  If the command button is designed to quit
  'the app, SendKeys will do that, because it "clicked" the button, itself.
  'So it is perhaps wisest to simply place a DoEvents statement at the end of each batch of SendKeys
  'statements.  That way, you know that all the contents of the SendKeys buffer have been properly sent
  'to the correct destination, and you don't have to worry about unsent info from then on, later on
  'in code.
  DoEvents

End Sub



Private Sub Quit_cmd_Click()
  End
 
End Sub

---

I have not tested your method but one solution is to format first the text into a richtextformat before sending/appending it to a richtextbox control, as such when the control receives the text it is already formatted...

I have done this, try searching the codebanks, there is a detailed sample on working with richtext there... :)

dee-u > Thanks for your response. This may be a stupid question, but what exactly are the codebanks? Do you just mean prior threads?

Codebank is a section of VBForums... Here is the link for RichTextBox, have a happy coding... :wave:

Cool. Thank you very much!

I have been updating the code above, all night. So if anyone has been trying out the code, you probably got a previous version. As I started working with this, I found many peculiarities concerning the SetFocus property and SendKeys. As a result, it seems best if the following flow is used:

1. Precede all SendKeys statements (or batch of statements) with the "Show" statement AND <textbox>.SetFocus to make sure that the SendKeys data is going to the correct destination.
2. Follow-up all SendKeys statements (or batch of statements) with "DoEvents" to finalize that SendKeys operation.

The new code edited into the original post above, has lots of new documentation in it concerning this. Don't be alarmed by the amount of text...95% of it is documentation (repeated in places, too). Tha actual running code is very small. The old code worked, it just failed when I tried to modify it for another application. After debugging it, this latest version is much more fault tolerant. I apologize if anyone has tried and had problems with the earlier versions. This will be the last version.

It may probably best not to use sendkeys for such, sometimes sendkeys works not according to the way you want it. :) If you could follow the sample in the codebank then you may find a better way to achieve your goal.

And also, it will be clearer if you will enclose your code with tags...

I went there last night to brief over what was there, but didn't have enough time to pull out any code that specifically formats a string as RTF. I will check today more thoroughly. Thanks for the tags suggestion. I'm going back to fix that.

dee-u:

I went to the codebanks and saved out the code. I was getting ready to go over it when I came across this solution on another forum. It is very compact and not convoluted like my previous attempt. So easy, it hardly needs any explanation at all:

Code:

---

Dim texto

Private Sub form_load()
'This is a quick method to get multi-formatted Rich Text into an RTB.
'It puts the text in an invisible RTB that is used only for formatting the string,
'then that RTB's contents are loaded into a visible RTB for display.
'The RTBs' multiline properties are set to "true".

End Sub

Public Sub Go_cmd_Click()
  RichTextBox2.Text = ""
 
  '---------------------------------
  texto = "Hello Earth!"
 
  RichTextBox1.Font.Bold = True
  RichTextBox1.Text = texto
 
  RichTextBox2.SelRTF = RichTextBox1.TextRTF
 
  '---------------------------------
  texto = "Goodbye Earth!"
 
  RichTextBox1.Font.Bold = False
  RichTextBox1.Text = texto
 
  'Since each additional text added to RichTextBox2 forces a linefeed,
  'this statement takes you back up one line, if you need to continue on the
  'same line:
  RichTextBox2.SelStart = Len(RichTextBox2.Text) - 1
 
  RichTextBox2.SelRTF = RichTextBox1.TextRTF
 
  '---------------------------------
  texto = "Destroy All Earthlings!"
 
  RichTextBox1.Font.Bold = True
  RichTextBox1.Font.Underline = True
  RichTextBox1.Text = texto
 
  RichTextBox2.SelRTF = RichTextBox1.TextRTF
 
End Sub

Private Sub Quit_cmd_Click()
  End
End Sub

---

Zip attached.

My point of pointing you that code in the codebank is for you to gain understanding on how to manipulate richtextbox and from that point on be better equipped with points on how to handle the problem you are pointing...

Got my point? :D

Yes indeed. I'm in the process of going through the code, as we speak.