>Нужно вызывать функцию для перевода с литералом как параметр.
1. мм… да заменил все строки типа s:='Apple'; на s:=_('Apple'); в файле po появились соотв. строки.
А автоматизации никакой для этого нет? В пакете Дельфи конечно есть GrepSearch, но все равно найденные строки пришлось обрабатывать вручную.
2. Так я не добавляю в OnShow каждой формы перевод, только в OnSHow главной формы перебираю в цикле все формы. Это происходит один раз при запуске программы. Ну и в функции переключении языка в runtime.
ps. программа конечно отличная и Вам спасибо за данный пост! В течение 1 дня фактически прикрутил перевод к существующему проекту, причем большую часть времени занимался именно переводом ))
1. Да, надо прочитать мануал еще раз )
Но по крайней мере в gorme данные из строк подобных (s:=('Apple'); ) не показывались. И соответственно не переводились.
2. Перевод не может менять шрифт, это всего лишь перевод, текст на входе — текст на выходе. Как выводить переведенный текст должно быть реализовано уже в Вашем приложении, потому как это уж очень кастомизировано у каждого
Ну как бы «только перевод» — да, но… увеличение длины строки это следствие перевода, и если утилита помогает решить эту проблему, то это только в плюс. Простейшее решение — уменьшить размер шрифта.
Но настаивать я не буду, это просто мысль )
4. Там же все равно надо первым вызывать Translate… а при смене языка Retranslate…
В моем случае программа (со всеми формами) уже написана и надо быстренько «прикрутить» туда мультиязычность. Менять структуру программы особой возможности нет.
1. Не переводит строковые литералы в файлах .pas?
2. В принципе параметром можно было бы прицепить размеры и стиль шрифта. Если перевод сильно длиннее оригинала, то выводить меньшим по размеру шрифтом.
3. В скриптике updatepofiles.cmd надо бы добавитьсохранение default.po в папке locale. Или я что-то не так делаю?
4. Перевод надо запускать по сыбытию OnShow главной формы, а не OnCreate.
Тогда можно перебором всех форм всех их перевести.
Как-то так для Дельфи
//**************************************************
procedure LangIni();
var
i: integer;
begin
for i := 0 to Application.ComponentCount - 1 do
begin
if (Application.Components[i] is TForm)
then translatecomponent(application.Components[i]);;
end;
end;
//**************************************************
procedure LangChange();
var
i: integer;
begin
for i := 0 to Application.ComponentCount - 1 do
begin
if (Application.Components[i] is TForm)
then Retranslatecomponent(application.Components[i]);;
end;
end;
procedure TForm0.FormShow(Sender: TObject);
var
i: integer;
begin
if RadioGroup1.ItemIndex=0 then
begin
LangC:='EN';
UseLanguage ('EN');
end
else
begin
LangC:='RU';
UseLanguage ('RU');
end;
LangIni();
end;
Все правильно — восприятие. Другое дело- непонятно, почему это восприятие в течение жизни привязано к конкретному носителю. И каковы критерии сложности объекта, к которому восприятие может быть привязано. Непонятно, является ли восприятие дискретным или непрерывным, возникает скачком или переходит от смутного пограничного состояния к полной «ясности сознания». В общем-то когда говорят «сознание», то подразумевают «восприятие», а не память, личность итп.
Италия в этом смысле отличилась не раз. Было дело, там дали реальные сроки ученым, неправильно предсказавшим силу землетрясения. Они сказали что будет «мало», а получилось «много» и на них навесили всех собак.
А кто будет делать-то? Что там их лицензия говорит насчет влезания в базу и пр.?
Компания -разработчик видимо хочет бабла срубить, а минздрав хочет сэкономить. И вся проблема.
А вот интересно, когда в штатах кончится лицензия на ПО для запуска ядерных ракет? Надо же знать момент!
Интересный кстати вопрос. Получается, что использование для счета 4-х фронтов потенциально опасно из-за влияния джиттера. И неважно как ведется обработка, программно или аппаратно, просто аппаратно быстрее и оно успевает обрабатывать фронты без пропусков.
Если обрабатывать по прерываниям, поймав переход канала В из low в hight и обрабатывая его, программа может пропустить переход обратно из hight в low. Соответственно насчитав по первому переходу +1, программа пропустит -1 по второму.
И пойдет дрейф показаний. Однако если для фиксации приращения +1 программа должна обрабатывать два перехода, то дребезг по одному из фронтов никак не будет влиять.
То есть по фронту канала В будет взводиться флаг готовности к счету, а по фронту канала А, при наличии флага будет производиться счет и сбрасываться флаг.
Тогда дребезг по любому фронту будет просто устанавливать (В) или сбрасывать (А) флаг, а счет производиться не будет. Чтобы был счет, вал должен повернуться как минимум на четверть шага.
Если исходный «аккорд» представляет собой сумму незатухающих «чистых синусоид» (по форме) и в выборке укладывается целое число периодов всех (каждой) составляющих аккорд «синусоид», то возможно произвести прямое и обратное преобразование Фурье и восстановить исходный сигнал без искажений.
1. Да, тут Вы правы. Надо этот момент в статье отметить отдельно.
По поводу вопроса.
1. Берем непериодическую функцию, определенную на всей оси X, от -беск до +беск.
2. Вырезаем из нее кусок от 0 до Т
3. Разлагаем этот кусок в ряд Фурье — представляем этот кусок в виде суммы ряда Фурье
Да, рядом Фурье будет представлена периодическая(!) ф-ция, представленная повторением вырезанного куска.
4. Если ее рассмотреть только на отрезке 0… Т (умножить на коробку), то, да, 4Б есть аппроксимация 2.
4.
1. Ну там же ниже в статье написано, что не поточечно )
2. Это зависит от задачи. С тем же успехом моно сказать, что «не надо забивать себе голову комплексными величинами, когда амплитуды и частоты — реальные»
3.>Если вы считаете, что вы не описались, тогда — ну не можете Вы комбинирую гармонические функции сложением получить не периодическую функцию.
Ну вот из-за подобного я и писал статью. И все равно…
Комбинируя гармонические функции мы получим функцию, совпадающую с нашим измеренным сигналом на отрезке измерения. Это все что надо. А вне этого отрезка функция будет периодически продолжена. Но в нашем конкретном случае это не важно.
И кто тут что не понимает ..))
4. Рассматривалось применение преобразование Фурье в сигналам. Поэтому. А так конечно, математическая теория гораздо шире.
Я в своих ограниченных задачах дискомфорта уже не чувствую. А люди которые, начинают изучать эту тему и у которых в голове смешались ряды Фурье и для периодических функций и преобразование — для непериодических, и много чего еще — конечно чувствуют дискомфорт.
>Преобразование Фурье не определено для sin,cos, единицы.
Ох… Еще раз — пафос статьи был в том, чтобы обратить внимание на ряды Фурье, как способ анализа сигналов.
Зачем сюда притягивать преобразование Фурье? Вот и получается каша ((
Теорема Котельникова — это математическая теорема ) У нее не может быть «недостатков», поскольку она математически верна (строго доказана). Проблемы применение мат аппарата к решению каких-то прикладных задач — это проблемы самих прикладных задач. Поэтому говорить, что " у теоремы есть определенные недостатки" или «она работает, хотя и плоховато» как-то несколько неправильно ).
Размажется, но… Некратность получится в пределах одного периода дискретизации, а на практике число отсчетов обычно достаточно велико, поэтому размазывание будет небольшое. Это для первой гармоники.
А для высших гармоник, я так понимаю, играет роль то, что за время измерения уложится много их периодов. Поэтому, хотя на один период ВЧ гармоники придется например 5 точек (некратность может быть в пределах 1\5 периода ВЧ гармоники), но за время измерения произойдет усреднение и размазывание уменьшится. Но это надо смотреть. (Студентам лабораторная работа :-)
А вот с амплитудой все хуже, она сильно уменьшается.
1. мм… да заменил все строки типа s:='Apple'; на s:=_('Apple'); в файле po появились соотв. строки.
А автоматизации никакой для этого нет? В пакете Дельфи конечно есть GrepSearch, но все равно найденные строки пришлось обрабатывать вручную.
2. Так я не добавляю в OnShow каждой формы перевод, только в OnSHow главной формы перебираю в цикле все формы. Это происходит один раз при запуске программы. Ну и в функции переключении языка в runtime.
ps. программа конечно отличная и Вам спасибо за данный пост! В течение 1 дня фактически прикрутил перевод к существующему проекту, причем большую часть времени занимался именно переводом ))
Но по крайней мере в gorme данные из строк подобных (s:=('Apple'); ) не показывались. И соответственно не переводились.
Ну как бы «только перевод» — да, но… увеличение длины строки это следствие перевода, и если утилита помогает решить эту проблему, то это только в плюс. Простейшее решение — уменьшить размер шрифта.
Но настаивать я не буду, это просто мысль )
4. Там же все равно надо первым вызывать Translate… а при смене языка Retranslate…
В моем случае программа (со всеми формами) уже написана и надо
быстренько«прикрутить» туда мультиязычность. Менять структуру программы особой возможности нет.2. В принципе параметром можно было бы прицепить размеры и стиль шрифта. Если перевод сильно длиннее оригинала, то выводить меньшим по размеру шрифтом.
3. В скриптике updatepofiles.cmd надо бы добавитьсохранение default.po в папке locale. Или я что-то не так делаю?
4. Перевод надо запускать по сыбытию OnShow главной формы, а не OnCreate.
Тогда можно перебором всех форм всех их перевести.
Как-то так для Дельфи
Компания -разработчик видимо хочет бабла срубить, а минздрав хочет сэкономить. И вся проблема.
А вот интересно, когда в штатах кончится лицензия на ПО для запуска ядерных ракет? Надо же знать момент!
Интересный кстати вопрос. Получается, что использование для счета 4-х фронтов потенциально опасно из-за влияния джиттера. И неважно как ведется обработка, программно или аппаратно, просто аппаратно быстрее и оно успевает обрабатывать фронты без пропусков.
Если обрабатывать по прерываниям, поймав переход канала В из low в hight и обрабатывая его, программа может пропустить переход обратно из hight в low. Соответственно насчитав по первому переходу +1, программа пропустит -1 по второму.
И пойдет дрейф показаний. Однако если для фиксации приращения +1 программа должна обрабатывать два перехода, то дребезг по одному из фронтов никак не будет влиять.
То есть по фронту канала В будет взводиться флаг готовности к счету, а по фронту канала А, при наличии флага будет производиться счет и сбрасываться флаг.
Тогда дребезг по любому фронту будет просто устанавливать (В) или сбрасывать (А) флаг, а счет производиться не будет. Чтобы был счет, вал должен повернуться как минимум на четверть шага.
Можно увидеть, что сигнал полностью восстанавливается.
Сигнал задается как сумма трех гармоник
xdata(i) = 16 * COS(th * 30) 'amp & Hz
xdata(i) = xdata(i) + 6 * COS(th * 6) 'amp & Hz
xdata(i) = xdata(i) + 4 * SIN(th * 14) 'amp & Hz
По поводу вопроса.
1. Берем непериодическую функцию, определенную на всей оси X, от -беск до +беск.
2. Вырезаем из нее кусок от 0 до Т
3. Разлагаем этот кусок в ряд Фурье — представляем этот кусок в виде суммы ряда Фурье
Да, рядом Фурье будет представлена периодическая(!) ф-ция, представленная повторением вырезанного куска.
4. Если ее рассмотреть только на отрезке 0… Т (умножить на коробку), то, да, 4Б есть аппроксимация 2.
4.
2. Это зависит от задачи. С тем же успехом моно сказать, что «не надо забивать себе голову комплексными величинами, когда амплитуды и частоты — реальные»
3.>Если вы считаете, что вы не описались, тогда — ну не можете Вы комбинирую гармонические функции сложением получить не периодическую функцию.
Ну вот из-за подобного я и писал статью. И все равно…
Комбинируя гармонические функции мы получим функцию, совпадающую с нашим измеренным сигналом на отрезке измерения. Это все что надо. А вне этого отрезка функция будет периодически продолжена. Но в нашем конкретном случае это не важно.
И кто тут что не понимает ..))
4. Рассматривалось применение преобразование Фурье в сигналам. Поэтому. А так конечно, математическая теория гораздо шире.
Я в своих ограниченных задачах дискомфорта уже не чувствую. А люди которые, начинают изучать эту тему и у которых в голове смешались ряды Фурье и для периодических функций и преобразование — для непериодических, и много чего еще — конечно чувствуют дискомфорт.
>Преобразование Фурье не определено для sin,cos, единицы.
Ох… Еще раз — пафос статьи был в том, чтобы обратить внимание на ряды Фурье, как способ анализа сигналов.
Зачем сюда притягивать преобразование Фурье? Вот и получается каша ((
А для высших гармоник, я так понимаю, играет роль то, что за время измерения уложится много их периодов. Поэтому, хотя на один период ВЧ гармоники придется например 5 точек (некратность может быть в пределах 1\5 периода ВЧ гармоники), но за время измерения произойдет усреднение и размазывание уменьшится. Но это надо смотреть. (Студентам лабораторная работа :-)
А вот с амплитудой все хуже, она сильно уменьшается.