Господа!
Прошу прощения за, возможно, странный вопрос. Но никто не сталкивался с проблемой ресайза с использованием указанной в сабже PFC-ишной функции? Попытаюсь пояснить. Входными параметрами этой функции являются значения в PowerBuilder Units. По коду этой функции программа пытается заресайзить требуемый объект в соответствии с этими параметрами. При этом по моим наблюдениям происходит "округление" задаваемых значений ширины и высоты объекта до пикселей (в соответствии с текущими настройками DPI в Windows). Т.е. при стандартных 96 DPI при попытке задать датавинде ширину, равную, скажем, 1188 PBU получим следующее:

integer li_Width
dw_1.Width = 1188
li_Width = dw_1.Width
// li_Width будет иметь значение, равное 1189

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

Сразу замечу, что я не работаю с чистым набором PFC-ишных библиотек, но функция pfc_n_cst_resize.of_Resize в моем случае заимствована целиком.
// PowerBuilder 9.0.2 Build 7661 (PFC, соответственно, от "девятки").

sboykoЭта функция правильно работает если не забыть задать ORIGINALSIZE.
Sboyko, можно попросить вас процитировать кусочек кода, где PFC-ишная обработка ресайза учитывает упомянутый ORIGINALSIZE?