Развитие русской справки

[ivsatel]

В справке http://autoit-script.ru/autoit3_docs/menu/total.htm
Есть сноска:

Применение HKCR64 или HKLM64 ключей реестра возможно при отключении механизма перенаправления, что описано в документации к функциям, работающих с реестром.

Но в описаниях функций будь то

RegDelete
RegEnumKey

И т.д. нет ссылок на этот механизм, имею ввиду:

DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)

Это актуально? Это нужно использовать?

 

[joiner]

в 64-среде используй HKLM64 и HKLM чтобы получить ключи реестра для 32-битных и 64-битных программ. справке об этом написано. использовал это в своей программе Run Control. программа писалась в Win 7 x64.

 

[AZJIO]

ivsatel
А зачем там ссылка на механизм, если он не действует для реестра? Механизм как бы внутренний, для различения каталогов на разных системах если он в двух вариантах.

 

[MON@H Rasta]

Предлагаю на страничке Заголовки и текст окон (расширенные) упомянуть о функции HWnd. Как вариант - сразу после заметки о том, что "дескриптор окна не рассматривается, как число или строка - это уникальный тип данных".

Спойлер: OffTopic

OffTopic:
Как новичёк в AutoIt (у Вас-то, гуру, восприятие уже другое ) искал-искал как из текста сделать дескриптор в переменной, потом просто создал тему с вопросом, да и всё. Хорошо, что не закидали помидорами за такие элементарные вопросы

 

[AZJIO]

MON@H Rasta
Посмотрел тему, это опять же ничего не решает вашу задачу, потому что дескриптор возвращает оконная функция и уже в правильном формате. Ни разу не использовал эту функцию, потому что вам придётся перевести дескриптор в строковый вид, чтобы потом опять преобразовать в дескриптор. При чём если указанное число не соответствует ни одному из существующих дескрипторов, то функция вернёт ошибку. То есть фактически можно копировать из Au3Info только для теста что функция работает, а в реальности программа же не будет запускать Au3Info, чтобы скопировать оттуда дескриптор. А некоторые функции, что получают дескриптор там указаны.

 

[AZJIO]

Обновлены по отдельности файлы справки
AutoIt3.chm - SRandom добавлено примечание
UDFs3.chm - Переведено 47 примеров _RichEdit... (остальные переведены частично)
Переведено 3 функции _WinAPI_...
Создано 11 примеров _WinAPI_..., которые не содержали примеров совсем.
CustomUDFs.chm - исправлена _DateDiff_2 (проверка входных параметров)
AutoIt.chm - На вкладке "Поиск" результаты не дублируются (исправление проблемы предложил gora).

 

[SyDr]

AZJIO, а разве @SEC принимает больше 60 различных значений?

 

[AZJIO]

SyDr

а разве @SEC принимает больше 60 различных значений?

Я поиском нашёл, что в качестве параметра используют time(), но в AutoIt3 нет этой функции, а исходников у меня нет, поэтому моё утверждение что @SEC делает функцию по умолчанию не совсем верно, но даёт понять что это всё же будет случайное число. Формулировку я выкладывал пару дней назад, никто не критиковал, и на офсайте пока никто не комментировал предложеный вариант ремарки.
По поводу больше или нет... ну база не является случайным числом, это всего лишь база, а Random будет работать с заданными параметрами, единственное что последовательность случайных чисел не будет постоянной.
Формулировка "Используйте SRandom(@SEC), чтобы функция Random выполнялась по умолчанию." не является точной, потому что я не знаю что в исходниках принимается за базу.

 

[inververs]

Я обычно делаю так:

SRandom(@AutoItPID)

 

[AZJIO]

inververs
При запуске скрипта нет смысла указывать SRandom, потому что Random и так работает нормально. А вот если вам требуется иногда работать с определённой последовательностью, а иногда восстанавливать обычную работу Random, то используя @AutoItPID, который не меняется при работе программы, вы тем самым запускаете заново одну и ту же последовательность случайных чисел. В итоге получается что @SEC более предпочтительнее. В крайнем случае если кажется что 60 значений это мало, то в качестве базы можно использовать

SRandom(Number(@MSEC & @SEC & @MIN &  @HOUR))

 

[AZJIO]

Обновлены файлы справки
UDFs3.chm
Переведено 10 функций _GUICtrlListBox...
Переведено 13 функции _RichEdit...
Переведено ещё 16 примеров _RichEdit...
Переведено 2 функции _WinAPI_...

CustomUDFs.chm
Добавлена функция _FO_IsDir, поправка в _FO_FileDirReName
Обновлены WM_HSCROLL, WM_VSCROLL

 

[AZJIO]

UDFs3.chm
Переведён раздел _GUICtrlDTP_... , всего 16 функций и 16 примеров.
Переведено 38 примеров _GUICtrlListBox...


Добавлено:

Сообщение автоматически объединено: 26 Ноя 2012

Обновил полный комплект, зеркало, описание в шапке.
Из последних обновлений - переведены все примеры _GUICtrlListBox...

 

[gora]

В справке у параметров работы с реестром (RegDelete, RegWrite, RegEnumKey и т.д.) есть примечание:

При работе в 64-битной Windows, если вы хотите получить значение параметра в 64-битной среде, вы должны указать суффикс HK ... с 64, например, HKLM64.

Мне кажется ;) это относится только к скомпилированным скриптам х86 и не скомпилированным скриптам запускаемым через х86 интерпетатор в 64-битной Windows. Если скрипт скомпилирован в х64 приложение или не скомпилирован и запускается через х64 интерпретатор в 64-битной Windows, то указывать суффикс нет необходимости.
Считаю, что данное уточнение следует добавить в примечание в справке, ибо для новичков это не является очевидным.

А есть ли "обратная" возможность: из х64 скомпилированного скрипта запускать команды работы с реестром в х86 среде? Этого я в справке не нашел...

 

[AZJIO]

gora

Мне кажется

Это надо проверить, чтобы точно знать. У меня нет 64 системы, чтобы проверить. Если знать точно, то я отпишу на офсайте и попровлю в справке.

Кстати примеры BitRotate и BitShift будут обновлены как здесь

 

[gora]

AZJIO [?]

Это надо проверить

У себя я проверил так:
Запускал не скомпилированный скрипт через х64 exe (скомпилированный AutoIt файл) с ключом /AutoIt3ExecuteScript
И без суффиксов, и с ними обращаюсь к одним и тем же х64 разделам реестра.
При запуске самого скрипта (двойным кликом) через х86 интерпретатор (у меня запуск выполняется через х86, а не через х64) наличие суффикса влияет на доступность х64 разделам реестра.

 

[AZJIO]

UDFs3.chm
Переведено 41 функции (из 46) _GUICtrlHeader_...

 

[AZJIO]

Перевожу _WinAPI_GlobalMemoryStatus, которая повторяет описание MemGetStats с разницей, что последняя округляется до килобайт.
Вопрос, почему файл подкачки 5 Гб, если у меня установлено так
Mинимaльный paзмep: 2 MБ
Peкoмeндyeтcя: 5182 MБ
Teкyщий paзмep: 2000 MБ

_WinAPI_GlobalMemoryStatus
23
3622940672
2774138880
5548851200
4301070336
2147352576
2086395904

MemGetStats
23
3538028
2704000
5418800
4204504
2097024
2039544

пример для теста

#include <WinAPI.au3>
#include <Array.au3>
$a = _WinAPI_GlobalMemoryStatus()
_ArrayDisplay($a, 'Информация о памяти')

Создаётся ощущение что виртуальная память перепутана с файлом подкачки.

 

[gora]

_WinAPI_GlobalMemoryStatus() на Win7 x64 вообще не работает.
Тестовый скрипт запускается, значок в трее висит пару секунд, потом пропадает и ни какого окна с массивом не появляется.

 

[AZJIO]

AutoIt3.chm
Поправки в Assign, MemGetStats

UDFs3.chm
Создано 3 примеров _WinAPI_GlobalMemoryStatus, _WinAPI_MultiByteToWideChar, _WinAPI_WideCharToMultiByte, они же частично переведены, в том числе _WinAPI_SetWindowPos. Последняя всвязи с интересным примером.

 

[AZJIO]

VarGetType

Возвращает строку, указывающую на внутренний тип указанного варианта.

хочу заменить на

Определяет тип данных переменной или значения возвращаемого выражением.

Не исказит ли это какое то представление о внутреннем типе?

Возвращает строковое представление типа выражения.

хочу заменить на

Возвращает строку, определяющую тип данных.

Далее примечание, которое я совершенно не понимаю.

IsInt может приводить к различным результатам, так как она пытается преобразовывать строковые или с плавающей точкой данные.

Причём здесь IsInt? Если в качестве сравнения с новой функцией VarGetType, то она также возвращает различный тип данных при строковых данных и с плавающей точкой.