[texworks] mouse-wheel / slider cause TeXworks inmediate crash, issue broadens

[Paul A Norman]

Hi,

Another thing I've noticed is that when I open a Tw document, and
particularly if I last closed the document in a larger sized window
than 'normal', Tw is taking a lot longer to fully open and give the
document t to me in an editable state than it used to.

Paul

On 27 January 2011 17:02, Paul A Norman <paul.a.norman at gmail.com> wrote:
> P.S.
>
> Thinking about it I realised that for other reasons since having my
> day of 14 crashes, I had reduced my Tw Editor/Preferences font-size.
> I am thinking this stopped the wrapped line width causing any
> problems.
>
> So a small temporary work around/or partial help may be to leave wrap
> line  on, but reduce your Editor font-size to 10pt, this is visually
> workable for me using the font "Liberation Mono".
>
> Paul
>
> On 27 January 2011 16:52, Paul A Norman <paul.a.norman at gmail.com> wrote:
>> Dear Stefan,
>>
>> On the 25th January according to my MS Application Events log, I had
>> 14 occurrences of this problem in a row, over an eight hour twenty
>> minute period. The system log over this time appears to show no
>> unusual events.
>>
>> Today after some four hours of very similar  Tw usage - so far no
>> crashes at all - go ask.
>>
>> One additional thing I have noticed and didn't think to comment on
>> originally, with this problem on Xp, sometimes Qt is causing Tw to
>> crash instantly with no User error message shown, nor User  error
>> reporting cycle. I'm not sure how it it getting "under the radar" like
>> that - possible the MS error number 1000 is just ignored as
>> untraceable.
>>
>> Or could this suggest that Qt is protecting User's system from a
>> massive overload of some sort.  An unstoppable cycle - or an
>> unbreakable loop of some sort?
>>
>> When following through the MS Application Events log - MS support says:
>>
>> "Currently there are no Microsoft Knowledge Base articles available
>> for this specific error or event message. "
>>
>> The Application Events log ...
>>
>> Event Type:     Error
>> Event Source:   Application Error
>> Event Category: None
>> Event ID:       1000
>> Date:           25/01/2011
>> Time:           6:18:21 p.m.
>> User:           N/A
>> Computer:       HENRY3
>> Description:
>> Faulting application texworks.exe, version 0.3.0.728, faulting module
>> texworks.exe, version 0.3.0.728, fault address 0x00fb0adb.
>>
>> Data:
>> 0000: 41 70 70 6c 69 63 61 74   Applicat
>> 0008: 69 6f 6e 20 46 61 69 6c   ion Fail
>> 0010: 75 72 65 20 20 74 65 78   ure  tex
>> 0018: 77 6f 72 6b 73 2e 65 78   works.ex
>> 0020: 65 20 30 2e 33 2e 30 2e   e 0.3.0.
>> 0028: 37 32 38 20 69 6e 20 74   728 in t
>> 0030: 65 78 77 6f 72 6b 73 2e   exworks.
>> 0038: 65 78 65 20 30 2e 33 2e   exe 0.3.
>> 0040: 30 2e 37 32 38 20 61 74   0.728 at
>> 0048: 20 6f 66 66 73 65 74 20    offset
>> 0050: 30 30 66 62 30 61 64 62   00fb0adb
>> 0058: 0d 0a                     ..
>>
>> Paul
>>
>> On 26 January 2011 08:39, Stefan Löffler <st.loeffler at gmail.com> wrote:
>>> Hi,
>>>
>>> On 2011-01-25 06:32, Paul A Norman wrote:
>>>> This seems to have broadened, or more is surfacing.
>>>
>>> My guess is the latter... especially since nothing has changed in the
>>> builds, recently.
>>>
>>>> In the debugger the crash can happen when the debugger adds error
>>>> lines itself as you click the  green Debugger arrow.
>>>
>>> This sounds reasonable, as the problem seems to be connected in some way
>>> to the line highlighting code (which I think is what is done in the
>>> debugger as well).
>>>
>>>> Also something strange, sometimes when material has been copied to the
>>>> clipboard in Tw, if it crashes due to this stuff, the material is no
>>>> longer on the clipboard.
>>>
>>> Yes, this is not entirely inexplicable. If the data is managed by Tw
>>> rather than the operating system, the data is naturally lost when Tw
>>> crashes. I am a bit surprised that this applies to simple plain text
>>> data, but who knows how Qt handles stuff internally.
>>>
>>>> It seems like a Qt framework issue?
>>>
>>> Indeed, I think so too. I've tried to get some help on the dev forums
>>> (http://developer.qt.nokia.com/forums/viewthread/3176/), but to no avail
>>> so far... :(
>>>
>>>> Do we need to retreat behind 4.7.1 for now?
>>>
>>> This would be an option, albeit not an ideal one. E.g., Ubuntu 10.10
>>> ships with Qt 4.7.0, and avoiding that would be quite difficult. The
>>> same thing will probably apply to 11.04, unless there is a new Qt
>>> release soon (which I seriously doubt). Similarly, for the Windows
>>> builds, I use a system that comes with 4.7.1 right now... All in all
>>> this is a big mess.
>>>
>>> -Stefan
>>>
>>
>