программа глючит после отправки SBM_GETPOS

[BLACK_RAIN]

Здравствуйсте. Объясните, что происходит.
Создаю скроллбар:

function CreateScrollBar(var handle:hwnd; owner:hwnd;
          caption : string; x,y,w,h : SmallInt): boolean;
begin
  handle :=CreateWindow('scrollbar', pchar(caption),
WS_CHILD or WS_VISIBLE or SBS_VERT,X,y,w,h, owner,0, hInstance, nil);
result := handle>0;
end;

      CreateScrollBar(ScrollbarHex, wnd,'', 0,0,20,90);

      sif.cbSize := SizeOf(tscrollinfo);
      sif.fMask := SIF_RANGE or SIF_POS or SIF_PAGE;
      sif.nMin := 0;
      sif.nMax := 20;
      sif.nPos := 0;
      sif.nPage := 2;
      SendMessage(Scrollbar, SBM_SETSCROLLINFO,1,LongInt(@SIF));

скроллбар работает и отправляет главному окну свои мессаги.
Потом где-то в коде делаю:

      n := SendMessage(Scrollbar, SBM_GETPOS, 0,0);
// code
// code
// code
..........
//code
      h := 0; //последняя строчка

После отправки сообщения SBM_GETPOS, программа выполняет только последнюю строчку в процедуре. Всё, что находится между SendMessage(SBM_GETPOS,0,0) и последней строчкой не выполняется.
Объясните доходчиво на пальцах что происходит?

      n := SendMessage(ScrollbarHex, SBM_GETPOS, 0,0);
      t := 'pppp';
      h := 0;
      s := 'jjjjjj';
      w := 0;
      t := 'kkj';
      MessageBox(wnd,PChar(IntToStr(n)),'',0);

Выполняются все строчки, кроме h := 0; и w := 0; компилятор их просто игнорирует.
Что происходит-то?

извините, не нашел, как сделать спойлер.
посмотрите на это!
104952584fae0e9ccb6feed4197fcf86.jpg
как такое может быть?
цикл for ix := 0 to 15 do начинается с 16 и идет до 0
в цикле for iy := 0 to RowsPerPage-1 do iy вообще всегда 0, но он выполняет первую строчку несколько раз и выходит.

[Stilet]

цикл for ix := 0 to 15 do начинается с 16 и идет до 0

Оптимизатор сработал. Если тебя это коробит перед циклом поставь {$o-} и {$o+} после цикла.

handle :=CreateWindow('scrollbar', pchar(caption),
WS_CHILD or WS_VISIBLE or SBS_VERT,X,y,w,h, owner,0, hInstance, nil);
result := handle>0;
end;

А что это за end такой? Доходчиво это сложно объяснить не видя кода полностью.

P.S. А зачем тебе Win API?

[BLACK_RAIN]

Сообщение от Stilet

Оптимизатор сработал. Если тебя это коробит перед циклом поставь {$o-} и {$o+} после цикла.

То есть, это нормально, что цикл for to, который должен идти от меньшего к большему, идет от большего к меньшему как for downto? Вы ничего не путаете? В чем тогда логика?
И вас не удивляет, что строчки 36-38 не выполняются? Почему они не выполняются? В другом проекте аналогичный код работает.

Сообщение от Stilet

А что это за end такой?

Это end от функции CreateScrollbar(), всё остальное из WM_CREATE.

Сообщение от Stilet

Доходчиво это сложно объяснить не видя кода полностью.

Что, серьёзно весь код выложить? Тогда вы сможете сказать, в чем дело?

Сообщение от Stilet

P.S. А зачем тебе Win API?

Сначала перешел на WinAPI ради уменьшения размера ЕХЕ и ускорение работы программ. Потом понял, что мне на WinAPI писать реально удобнее. Сейчас на VCL писать вообще не могу.

[p51x]

То есть, это нормально, что цикл for to, который должен идти от меньшего к большему, идет от большего к меньшему как for downto? Вы ничего не путаете?

Абсолютно нормально, если нет зависимостей. Более того умный компилятор вообще может ссе инструкции воткнуть.

В чем тогда логика?

Это оптиминальнее на данной архитектуре процессоров и их наборе инструкций.

И вас не удивляет, что строчки 36-38 не выполняются? Почему они не выполняются?

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

Сейчас на VCL писать вообще не могу.

А канвас это тоже винапи?

[waleri]

Отключите оптимизации, все заработает.

[Stilet]

То есть, это нормально, что цикл for to, который должен идти от меньшего к большему, идет от большего к меньшему как for downto? Вы ничего не путаете? В чем тогда логика?

Абсолютно. Оптимизатор переводит цикл в ассемблер, где удобнее циклы гонять с конца, если использовать команду loop, а ECX как итератор цикла. Именно так оптимизаторы и поступают причем еще с Turbo Pascal 5.

вас не удивляет, что строчки 36-38 не выполняются? Почему они не выполняются? В другом проекте аналогичный код работает.

Warning читать не пробовал? а стоит - там написано почему эта часть кода выкинута оптимизатором.

Что, серьёзно весь код выложить? Тогда вы сможете сказать, в чем дело?

Ниче себе заявление... О_о
а если я скажу - "Неа", чего делать будем? Дальше гадать, что у тебя там не так?
Ладно. Проехали. Не выкладывай.

[BLACK_RAIN]

Сообщение от Stilet

Абсолютно. Оптимизатор переводит цикл в ассемблер, где удобнее циклы гонять с конца, если использовать команду loop, а ECX как итератор цикла. Именно так оптимизаторы и поступают причем еще с Turbo Pascal 5.

недавно писал такой код:

for i:=0 to 10 do
  listbox.add(inttostr(i));

Почему строчки добавлялись по порядку 0-10? ассемблер понял, что я пишу не на WinAPI и стал гонять циклы с начала?
в чем тогда разница to и downto? И вообще, почему всегда нормально работало, а сейчас ассемблер захотел перебирать с конца?
у меня не один WinAPI проект. В других проектах тоже есть циклы for i:=0 to n-1 do begin и там I сначала равна 0 и увеличивается до n. Почему там это работает так, а здесь по другому?

насчет оптимизации и выкидывания компилятором лишних строчек:
Да-да, я в курсе. Тема уже обсуждалась. Мне советовали выключить оптимизацию (это, кстати, не помогло). Но тогда была немного другая проблема. Строчки не выкидывались, а просто дебаггер не показывал значения некоторых переменных. Но сейчас не об этом.
Еще раз. Вот код.

procedure drawHEX;
var
//{  buf : array [0..1] of Char;
  t : string;
//  r : TRect;
//  i : Integer;
  ix, iy,  x,y,a : Integer;
begin
//  CurrentPos := ScrollBR_GetPosition(ScrollbarHex);
//  i := SendMessage(ScrollbarHex, SBM_GETPOS,0,0);
  x := 4;
  a := 9;
  ix := 0;
  iy := 0;

  for iy := 0 to RowsPerPage-1 do
  begin
    if ScrollbarPos >= FileSize then Break;
    for ix := 0 to 15 do
    begin
      if ScrollbarPos >= FileSize then Break;
      t := IntToHex(bytesarray[ScrollbarPos],2);
      bmp.Canvas.TextOut(x,y,t);
      canv.Draw(0,0,bmp);
      x := x + fontWidth*3;
      inc(ScrollbarPos);
    end;
    x := 4;
    inc(y, FontHeight + RowsInterval);
  end;

  canv.Draw(0,0,bmp);
end;

Вы говорите, что оптимизатор выкинет строчки a := 9; ix := 0; iy := 0;. Ладно, пусть выкидывает. Но почему при входе в цикл for iy := 0 этот iy равен 325910528 и цикл проходит не весь?
p.s. Сейчас включил оптимизацию и вернул остальные галочки так, как было на момент создания темы. Результат: строчки не выкидываются и циклы идут от 0 до n. Кто там говорил про ассемблер? Почему же теперь снова стало от 0 до n?

[p51x]

Почему строчки добавлялись по порядку 0-10? ассемблер понял, что я пишу не на WinAPI и стал гонять циклы с начала?

Нет. ВинАпи тут не причем. Читайте мой пост, тут явные зависимости.

В других проектах тоже есть циклы for i:=0 to n-1 do begin и там I сначала равна 0 и увеличивается до n. Почему там это работает так, а здесь по другому?

Читайте, что вам пишут.

Но почему при входе в цикл for iy := 0 этот iy равен 325910528 и цикл проходит не весь?

Потому что еще не было начальной инициализации и там могло быть, что угодно.

p.s. Сейчас включил оптимизацию и вернул остальные галочки так, как было на момент создания темы. Результат: строчки не выкидываются и циклы идут от 0 до n. Кто там говорил про ассемблер? Почему же теперь снова стало от 0 до n?

Ну мы откуда знаем, что вы там на включали-навыключали. Может просто не перекомпилили.

[BLACK_RAIN]

Сообщение от p51x

Потому что еще не было начальной инициализации и там могло быть, что угодно.

ЧТО??? Троллинг пошел, да? Иначе, всего ранее сказанного просто не было.

[p51x]

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