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

[Paul A Norman]

On 21 December 2010 09:30, Stefan Löffler <st.loeffler at gmail.com> wrote:
> On 2010-12-16 00:06, Paul A Norman wrote:
>> Just double click on it, establishes its own shell session for responses.
>
> Sounds good.
>
>> And works perfectly, problem does not reoccur.
>

Yes there are so many differences obviously between this direct
applying of the data to the Script engine and the full process that Tw
goes through in loading / establishing / delpoying a script.

> Also sounds good in itself, but bad in the sense that it doesn't really
> bring us closer to resolving the issue in Tw. It only suggests that
> there is indeed some problem in our code :(.

Unless something potentially relevant was known to have been be
changed in Tw - I would tend to probably still look to some change in
Qt Framework.

Can you think of anything in Tw that could actually cause this?

Only thought I have had - is there any where that Tw needs to
explicitly tell Qt in C++ that dropdown type dialogues need to be
treated as case sensitive?

What I am thinking is that may be this was once the default in Qt (so
Tw set nothing and things just worked  - as they used to with this in
Tw, ) and then they changed Qt to require it to be explicitly stated -
or it is broken in there? Or some such thing.
There was something I read a few weeks ago and I have not found my way
back to it yet to check what the details were  actually all about it
might be this ...

I'm not a C++ guy as you know but maybe there is something that  now
needs to be set with QStringList about case sensativity
Qt::CaseSensitivity cs = Qt::CaseSensitive
It seems that should not be necessary as CaseSensative is the default
but may be it needs to be set as something is broken somewhere in
newer Qts ?

http://doc.qt.nokia.com/stable/qstringlist.html

getItem is using QStringList it seems probably to get the User's
choice. It almost seems that Qt searches the array to match it and
CaseInsensatively finds the first match to the actual choice - which
may not be the actual item the User has chosen?

Wild thoughts ... but there you are.

Recap - Somehow with AAA Abc, abc, ABC  for choices above position [0]
eventually only Abc will be returned no matter what is chosen.

> BTW: does the problem persist with the latest test builds of Tw (i.e.,
> with those using Qt 4.7.1)?

Yes, I have today tried it on your last - 726 and it kicked in on the
fourth of fifth use of the drop down getItem(). At first it was ok,
but for some reason it kicks in later sometimes.

Annoyingly fickle. I just can;pt think what might be affecting it.

I' think I have ruled out the fact that you are cross compiling, as it
does it on the last version I compiled actually under Xp, on a
different machine to my work one,  my self which was 649 (marked
personal)

For consistency with these sorts of things I have been relying on your
releases since then.

Paul

>
> -Stefan
>