[texworks] We've reached r700+; please test

[Paul A Norman]

Thanks Stefan,

That's really great thank you.

Sorry to be a bearer of these things ...  (was 701 compiled under
Windows - don't know if it matter or not just wondering?)

Ok I'm getting some crashes and freezes under build 701

1. I think this was covered by someone else earlier - but in case
still relevant  - Windows Xp SP3 Tw File Open takes up to ten or even
more seconds to present the dialogue box.

I'll run all these following ones here and not in separate Issues as
they may all be due to the same, one, new innovation/ change perhaps?

2. TwMenu//Edit/Preferences/Scripts
    Tick or untick the Script Writing check box and things will either
freeze permanently when you ok the dialogue, or hang for about nine
     seconds.

     Here are the MS error dump files from one actual crash if they help at all.

     http://dl.dropbox.com/u/13401476/TeXworks%20Edit-Preferences-Script-Write%202010%2012%2004.zip

3. After using edit. Preferences to do with scripting write, and
experiencing a five-seven second hang with out a permanent freeze-up,
the next Alt Scripting short-cut key used will crash the programme

4. Sometimes (fickle) with a new unsaved document scripting shortcuts
just don't work

5. Sometimes (fickle) especially in an unsaved document, after
changing Edit/Preference/Script Write or Plugin Lua/Python setting,
shortcuts just don't work or crash Tw.

Might be all the same thing in code?

Paul

On 4 December 2010 22:18, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> On 2010-12-04 08:09, Paul A Norman wrote:
>> /Q_INVOKABLE
>> int TWScriptAPI::writeFile(const QString& filename, const QString&
>> content) const
>>
>> 1. Ok, so const QString& filename is a fully qualified path?
>>
>> Through Qt internals, does the path default to anything if no path is given?
>
> Duh, I don't know how I could have overlooked this - thanks for noticing
> and reporting.
> Starting from r703, relative paths are taken to be relative to the
> folder containing the calling script's file. So if you have a script
> file <resources>/scripts/test/abc.js, a call to TW.writeFile("xyz.log",
> ...) will create a file <resources>/scripts/test/xyz.log
>
> Before, Qt would internally take the current working directory. In my
> brief tests this seemed to default to the script file's folder, but if
> this holds in general I don't know.
>
>> Stefan, you mentioned that const QString& content is going to write as UTF-8
>>
>>   umBytes = fout.write(content.toUtf8());
>>
>> 2. If  QString& content is only ascii will that as expected only
>> render as Ascii in that utf-8 doesn't kick in unil after ascii 127(?)
>> - is that right? Ascii to 128 will still be saved as a single octet?
>> Qt doesn't do anything unexpected here?
>
> Yeah, ASCII should not change at all. As for anything beyond ASCII, it
> depends on how the strings are constructed. Internally, Qt uses some
> unicode encoding (don't ask me which exactly). So when constructing
> strings, you have to be careful to make Qt convert the encoding in which
> your string is given into its internal encoding. For QtScript files, I'd
> expect this to work out-of-the-box, though, since all strings are stored
> as QString objects (e.g., for python, however, there is a distinction
> between "normal" strings and unicode strings at least in some version).
>
>> 3. And the int returned on success/failure, is there some hint as to
>> cause of failure available?
>>
>> Looks at moment like just   SystemAccess_Failed    or
>> SystemAccess_OK  -  is that right?
>
> Yes, and no. There are three return values:
>        SystemAccess_OK = 0,
>        SystemAccess_Failed = 1,
>        SystemAccess_PermissionDenied = 2
> PermissionDenied is returned when writing is disabled. If it is enabled,
> though, and writing fails, there is no further distinction (e.g.,
> whether you are trying to write to a folder that doesn't exist, or to a
> file that is protected by some system's permissions, etc.).
>
>> For text files returnFileContents() will be really really helpful :)
>
> Yes, yes, this is planned and in the making ;).
>
> Cheers,
> Stefan
>