[wx-dev] wxRichTextCtrl GetStyle() bug?

Tom Gersic wxdev at teleologic.net
Wed Jan 24 11:52:13 PST 2007


Julian,

This works perfectly. Thank you.

One other problem that I've noticed with wxRichTextCtrl is that when you 
have a link at the end of a line, that link carries all the way over to 
the right side of the control. The link doesn't show up visually, but 
the mouse cursor changes to a hand, and a click will activate the link, 
even though the mouse isn't placed over the link. Here's an image that 
illustrates the issue:

http://gersic.com/files/wxRichTextCtrl3.jpg

Thanks,
Tom

Julian Smart wrote:
> Sorry, I didn't read ahead to see your links to the sample.
>
> What's happening is this: when the first style is read, paragraph 
> versus character attributes is unspecified, and so by default it takes 
> the leaf object and retrieves the URL style. However, because it's 
> retrieving the combined style which includes paragraph formatting, 
> this also sets the attr object's style flags to paragraph, and this 
> indicates to the next call of GetStyle that it should look at the 
> paragraph attributes, and not the character formatting. So if you 
> reset the flags e.g. with attr.SetFlags(0) each time, you should get 
> the desired results.
>
> I'm not sure if GetStyle's behaviour is entirely desirable, but the 
> idea is to allow the app to get either the paragraph or character 
> style depending on what you're interested in. To get the raw leaf or 
> paragraph style uncombined with parent styles, you can use 
> GetUncombinedStyle.
>
> Regards,
>
> Julian
>
> Julian Smart wrote:
>> Hi Tom,
>>
>> Sorry about this, I don't have any information about it but if you 
>> manage to patch the wxRichTextCtrl sample to make it easy to 
>> reproduce, I'll definitely give it a whirl in the debugger to see if 
>> I can spot the problem.
>>
>> Thanks,
>>
>> Julian
>>
>> Tom Gersic wrote:
>>> Hi,
>>>
>>> I think there may be a bug with the wxRichTextCtrl GetStyle() 
>>> command, but I can't quite isolate it. What I'm trying to do is to 
>>> look at a particular location in the text (say, character 40), and 
>>> check whether the wxTEXT_ATTR_URL is set at that location. If it is 
>>> set, I want to find where that flag starts and ends (i.e. the 
>>> beginning and end of the link). So, I'm simply setting up a loop to 
>>> search for the start position of the link:
>>>
>>>        //for the purposes of this email, assume that characters 20 
>>> through 50 have wxTEXT_ATTR_URL set
>>>        int startLocation = 40;
>>>        wxRichTextAttr attr;
>>>        daTextCtrl->GetStyle(startLocation, attr);
>>>
>>>        while(attr.HasFlag(wxTEXT_ATTR_URL) && startLocation > 0)
>>>        {
>>>            startLocation--;
>>>            daTextCtrl->GetStyle(startLocation, attr);
>>>        }
>>>
>>>        wxMessageBox(wxString::Format("%d",startLocation));          
>>> Now, I know for a fact that the link starts at character 20, and 
>>> extends to character 50, so startPosition *should* equal 20, but it 
>>> always goes through the loop exactly once, and comes back with (in 
>>> this instance) 19. If I add a watch for attr.HasFlag, it does indeed 
>>> return true the first time and false the second time I check....even 
>>> if I don't subtract 1 from startLocation. So, for instance, if I do 
>>> this twice...
>>>
>>> daTextCtrl->GetStyle(startLocation, attr);
>>> attr.HasFlag(wxTEXT_ATTR_URL) ;
>>>
>>> ...the first time it will return true, and the second time it will 
>>> return false.
>>>
>>> What's going on here?
>>>
>>> Thanks,
>>> Tom
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: wx-dev-unsubscribe at lists.wxwidgets.org
>>> For additional commands, e-mail: wx-dev-help at lists.wxwidgets.org
>>>
>>>
>>>
>>
>>
>
>




More information about the wx-dev mailing list