Fast way to 'plain text' rich text?

[rsts]

I have note documents which may or may not contain rich text. I would like to 'preview' the items in a listicongadget so the user can select the appropriate note, which will then be displayed in an editorgadget.

I would like the listicongadget display to be just the text of the (possibly) rich text contents - i.e. not display all the rtf control data as part of the listicon display.

example: Instead of displaying -
{\rtf1\ansi{\fonttbl\f0\fswiss Helvetica;}\f0
Hello!\par
This is some {\b bold} text.\par
}

The listicongadget will display

Hello! This is some bold text.

Is there a fast way to convert the rich text to plain text for display in the listicongadget? (Like maybe some API?). I would prefer not to use the clipboard since I don't particularly want to alter it's normal contents.

cheers

[srod]

A real dirty way:

http://www.purebasic.fr/english/viewtop ... tor+gadget

[rsts]

Thanks srod. I may have to resort to something like this.

I had thought of this and using the clipboard as possible alternatives, but was hoping for a little 'cleaner' way. Hiding the editorgadget will eliminate the 'flickering' I don't want the user to see. I'll have to run some timing tests on this and see how it performs.

Thanks again.

[srod]

It should be quite quick with the only delay arising from actuallly loading the rtf content into the gadget. Once that is done, there is no more 'internal' conversion required as retrieving the text amounts to no more than a #WM_GETTEXT message.

I would think this would only be marginally slower than using some dedicated rtf parser as of course a Windows rich edit control comes equipped with it's own!

[rsts]

Yes, an 'unparser' would probably offer only marginal benefit, if any.

I was hoping for some sort of API call. Short of that, this is probably as good an option as I'll find. I'll give it a try and see how it performs.

Thanks again for your assistance. Fred ought to put some of you guys on the payroll. I'd donate.

cheers

[alban]

In case this helps:
I have some Base64 encoded RTF files that I display as plain text in Linux edit views.
With my particular files I am getting away on Linux with eating the markup based on the fact that it seems to start with a \ and end with a space.
Once you have eaten everything between \ and space you then have to eat everything left between the opening curly brackets and the semicolon.
You follow this by eating the remaining closing curly brackets.
This may not be enough for all documents but works for the ones I am using that started life as paragraphs copied from Wordpad. I am not sure the cut and paste trick works unless you are running windows.

Code: Select all

Procedure.s BASE64RTFToText( value$)
 L=Len(value$) 
 If L>0 
 *decodeBuffer=AllocateMemory(L)
 If *decodeBuffer<>0
   L = Base64Decoder(@value$, L,*decodeBuffer,L)
   value$=""
   ; purge RTF 
   While i<L
    c=PeekB(*decodeBuffer+i)
    If c=Asc("\"); skip rtf
     Repeat
     c=PeekB(*decodeBuffer+i)
     i + 1
     Until c=32 Or c=13 Or c=10
    ElseIf c=Asc("{")
     Repeat
     c=PeekB(*decodeBuffer+i)
     i + 1
     Until c=Asc(";")
    ElseIf c=Asc("}")
     i + 1
    Else
    value$+Chr(c)
    i + 1
   EndIf
  Wend
  ; skip leading whitespace
  i=0
  Repeat
  i + 1
  c$=Mid(value$,i,1)
  Until c$>" "
  value$=Right(value$,1+Len(value$)-i)
  FreeMemory(*decodeBuffer)
 EndIf  
 EndIf
 ProcedureReturn value$
 EndProcedure

[pureballs]

I looked this up, as I am busy with exactly the same thing.

The MS Rich Edit control until version 4.1 does not have an option to block rich pasted input, but 4.1 does !

The name of the Rich Edit control has changed a few times :

1.0 Riched32.dll RICHEDIT_CLASS
2.0 Riched20.dll RICHEDIT_CLASS
3.0 Riched20.dll RICHEDIT_CLASS
4.1 Msftedit.dll MSFTEDIT_CLASS

as shown in this document : http://msdn.microsoft.com/en-us/library ... S.85).aspx

As you can see when you scroll down, 4.1 has a property called : EM_SETTEXTMODE

which saves you a lot of work and will make medium and big documents work as fast as small ones, as the rich input data will be ignored instead of processed.

So... do we have to use the Msftedit.dll or will there be a new or extra purebasiclibrary / wrapper ?

Regards,
Pure Balls.

[pureballs]

This is the way people try to deal with it in VB :

http://www.xtremevbtalk.com/archive/ind ... 36570.html

Maybe there's a clue in that gibberish.