[texworks] SCRIPTS: TW.getItem() returning everything lower case?

[Paul A Norman]

Ok more accurate osilation of problem,

There appears to be something about the way that the lists are built
internally by recent versions of Qt perhaps.

The behaviour is not fickle but seems to be predictable. It appears
that it actually has nothing to do with uppercase / lowercase as such.

If items in a list are case-insensitively the same, then the first
occurrence of a common sequence of letters seems to typecast the rest
- they are all recognised as the same.

["ABCD", "abcd","Abcd","ABCD", "Efgh"]

First three elements are always coming out as ABCD


[ "abcd","ABCD","Abcd","ABCD", "Efgh"]

First three elements are always coming out as abcd


["Abcd", "abcd","ABCD","ABCD", "Efgh"]

First three elements are always coming out as Abcd


Efgh is always exactly as wanted, as there is no earlier occurance.

Use this however

["Abcd","abcd","ABCD","ABCD","Efgh", "EFGH"]

And try for EFGH and you'll get Efgh.

I struck this because LaTeX font size names are case mixed and
sometimes the same in strict letters.

["tiny","scriptsize","footnotesize","small","normalsize","large","Large","LARGE","huge","Huge"]

And where there is a common alpha-bet series, the lowercase is always
given first in the list, so I thought Uppercases were being converted
to lowercases.

Paul


On 9 December 2010 10:48, Paul A Norman <paul.a.norman at gmail.com> wrote:
> Dear Stefan,
>
>>Could you test with a list of strings that contains no (entirely)
> lower-case entries?
>
> The problem is that fickly, but most often, Uppercase letters are
> treated/converted to lower-case
>
> In the graphic in the last email,
>
> http://dl.dropbox.com/u/13401476/general_images/TW.getItem_fickle_problem_lowercase_returned.jpg
>
> The results of progressively going through the array are shown.
>
> The array that I went carefully through with the item box one by one was
>   ["tiny","scriptsize","footnotesize","small","normalsize","large","Large","LARGE","huge","Huge"]
>
> And the corresponding  results of each progressive use of the item box were ..
>
>   tiny  scriptsize  footnotesize  small  normalsize  large  large
> large  huge  huge
>
> I have kept the previous compilations of TeXworks, and have tried 0.3
> rev 606 and this problem is **not** found there at all.
>
> It does happen in 0.3 ver 649
> It does happen in 0.3 ver 684 and so up...
>
> Paul
>
> On 9 December 2010 08:23, Stefan Löffler <st.loeffler at gmail.com> wrote:
>> Hi,
>>
>> On 2010-12-08 00:36, Paul A Norman wrote:
>>>> The only
>>>> thing that has changed (at least in my Windows builds, compared to
>>>> before) is the version of Qt.
>>> What version of Qt is being used at present please - 4.7 - as in help about?
>>
>> Yes, Qt 4.7.0.
>>
>>> Its fickle - sometimes it happens (mostly), sometimes it doesn't, in
>>> successive calls to the script - only occurrence of this that I am yet
>>> aware of in anything that I am using on this computer at present.
>>>
>>> Here is an image showing what repeated running of the script shown
>>> does, as described in the comment line. The results were being
>>> inserted in the Scirpt's file in Tw as it was used.
>>>
>>> http://dl.dropbox.com/u/13401476/general_images/TW.getItem_fickle_problem_lowercase_returned.jpg
>>>
>>> The message box in the image should show:    Huge
>>
>> Could you test with a list of strings that contains no (entirely)
>> lower-case entries? So we can determine if this is actually a problem of
>> case, or of selecting the wrong item ("huge" instead of "Huge")?
>> As you already saw in the code, the getItem function is basically a
>> direct wrapper around the native Qt function QInputDialog::getItem. So
>> unless something weird happens in passing data to/from scripting, this
>> seems very much like a Qt bug (if any) to me.
>>
>> -Stefan
>>
>