выгрузка и загрузка буфера анализа графики

[h31p]

 часто стоит задача проанализировать, так скажем, многоуровневую структуру на экране - в которой надо что-то щёлкать и гетскринить для уточнения - но так, чтобы после этих уточнений продолжить анализировать именно первоначальный снимок.
 в нынешней модели, если я правильно понимаю - это невозможно, после последующих гетскринов изначальный теряется безвозвратно. или я плохо искал, но вроде перечитал всю справку

вариант "сначала всё проанализоровать, потом всё уточнять", к сожалению, не всегда возможен, делает код слишком громоздким, и отрицательно сказывается на потреблении памяти.

проблему решила бы пара новых функций, одна для выгрузки всего текущего буфера в файл, вторая для загрузки такого файла обратно в буфер.

и/или, как вариант - несколько рабочих буферов в памяти + функцию выбора активного, с которым дальше работаем.

если это не слишком напряжно - хотелось бы такой ништяк в последующих версиях.

и спасибо вам за вашу работу и за сей отличный продукт

[Vint]

Можно пример использования? Вот, честно, ни разу подобное не понадобилось. Или понять где это можно использовать или убедиться, что можно обойтись правильным подходом.

Вру, была одна необходимость, но пока её не буду озвучивать. Тем более, там не всё так просто.

P.S. выгрузка и так есть - это SCREENSHOT, осталась загрузка.

[dramster]

Если требуется не большой участок экрана, то можно сохранить его к примеру в массив, и в нужный момент снова подгрузить в графический буфер тем же pxlreplace.

[h31p]

Можно пример использования?

ок, реальный пример, который побудил высказать такое пожелание.
в определённый момент на экране появляется некий маркер, на который нужно нажать, из всплывшего диалога выдернуть кусочек изображения, затем диалог закрыть, и выдернутый кусочек найти на экране и по нему кликнуть.
нюанс в том, что всплывший диалог может перекрыть само изображение которое нужно найти и нажать, а оно, в свою очередь, есть кадром незамкнутой анимации, т.е. на экране до нажатия маркера и во всплывшем диалоге они точно совпадают, а после закрытия диалога - уже не факт, то есть вариант доп. гетскрина после закрытия диалога - скорее всего не прокатит. ситуация усугубляется тем, что подопытный писан на flash, о тормознутости которого говорить нет нужды - там только открыть-закрыть диалог хватит по времени на то, чтобы изображение сменилось.

Вот, честно, ни разу подобное не понадобилось. Или понять где это можно использовать или убедиться, что можно обойтись правильным подходом.

я сталкивался с подобными потребностями и раньше, но выкручивался "костылями" на базе того что есть - выгрузкой всех возможных вариантов в массивы и анализом-действиями постфактум. такой подход возможен, но граничит с абсурдом - анализировать всё, чтобы использовать в итоге 1%. но других вариантов пока, увы, нет, а будь такой инструмент доступен - код стал бы намного короче, быстрее, и главное - логичнее.

P.S. выгрузка и так есть - это SCREENSHOT, осталась загрузка.

ну тут уже уважаемому автору виднее, как лучше. может есть смысл буфера грузить-выгружать "как есть" в какой-нибудь .bin или .buf, чтоб не было лишнего оверхеда внутри СМ и лишней путаницы снаружи. хотя соглашусь, при грамотном использовании возможность грузить .bmp непосредственно в буфер анализа - более универсальна, и решила бы не только эту проблему.

[h31p]

Если требуется не большой участок экрана, то можно сохранить его к примеру в массив, и в нужный момент снова подгрузить в графический буфер тем же pxlreplace.

да как бы вопрос не в размере, памяти у современных компов на всё хватит, и мощи пережевать это всё обходными путями тоже.
вопрос в том, что если так приходится делать - почему бы не отнести это всё поближе к железу, чтоб писалось красиво, и выполнялось быстро.

[dramster]

Примеров не могу вспомнить, но потребность загрузки в буфер из файла у меня также возникала. Как то находил обходные пути. Я то конечно за расширение функционала, но востребована данная процедура скорее всего не будет.

[Cleoss]

я сталкивался с подобными потребностями и раньше, но выкручивался "костылями" на базе того что есть - выгрузкой всех возможных вариантов в массивы и анализом-действиями постфактум.

уважаемому автору виднее, как лучше. может есть смысл буфера грузить-выгружать "как есть" в какой-нибудь .bin или .buf, чтоб не было лишнего оверхеда внутри СМ и лишней путаницы снаружи. хотя соглашусь, при грамотном использовании возможность грузить .bmp непосредственно в буфер анализа - более универсальна, и решила бы не только эту проблему.

Мне так и представилось сразу: записать массив в обычный текстовик. А сама Винда, если не ошибаюсь, пишет данные буфера в файлы .clp или раньше так было.

[dramster]

По вопросу загрузки в графический буфер изображения из файла.

Вижу, в новой версии 4.14 "Инструкции, предназначенные для работы с файлами и файловой системой". Руки зачесались потестить  . И тут как-раз задача для которой применимо чтение файлов побайтово FREADDATA.

Работает шустро. Теперь из лубого файла можно прочитать любой блок информации  .

К примеру из БМП можно прочитать его размеры, битность и прочее.

А вот и пример по загрузке картинки напрямую в графический буфер:

Код: Clickermann

SUB(bmpToClip, $name, $x_in, $y_in) //параметры - имя файла, координаты вставки картинки (верхний левый угол)
   UNDEFINE($arr_bmp)
   FREADDATA ($name, $arr_bmp)
   $pix_data = $arr_bmp[10]  //начало пиксельных данных
   $Width = $arr_bmp[18]+$arr_bmp[19]*256 //ширина
   $Height = $arr_bmp[22]+$arr_bmp[23]*256 //высота
   $ByteCount = $arr_bmp[28]/8 //байт на пиксель. 24бит или 32бит
   //   print($pix_data)
   //   print($ByteCount)
   print($Width,"x",$Height)
 
   FOR($y=$y_in+$Height-1, $y > $y_in-1, -1)
      FOR($x=$x_in,$x<$Width+$x_in)
         PXLREPLACE ($x,$y,$x,$y,-1,COLORGEN($arr_bmp[$pix_data+2],$arr_bmp[$pix_data+1],$arr_bmp[$pix_data]))
         inc($pix_data,$ByteCount)
      END_CYC
      //паинт.нет после каждой линии по Y добавляет ненужный байт :/
      //возможно это у всех 24битных бмп-шек
      //inc($pix_data,1)//убираем его вот этим
   END_CYC
END_SUB

Сильно не тестил. Заметил лишь то, что при сохранении картинки в 24бит из паинт.нет, после каждой линии по Y там какойто левый байт сидит  , приходится пропускать его. Инфы про этот байт не нашел.