Розібрався, набрав модуль і устройл Scroll, але виник ще питання.
Як зробити так, щоб при зменшенні розміру вікна не тікав бігунок дуже далеко? Тобто при стандартно відкритому вікні все нормально крутиться, але варто поміняти розмір вікна, як scroll можна засунути на дуже велике значення вниз \ вліво.
І ще залишається слід, як від нього позбутися? Перемальовування за допомогою refresh не допомогла. Вона просто форму перемальовує, але не оновлює.
Kekir писал (а): Як зробити так, щоб при зменшенні розміру вікна не тікав бігунок дуже далеко? Тобто при стандартно відкритому вікні все нормально крутиться, але варто поміняти розмір вікна, як scroll можна засунути на дуже велике значення вниз \ вліво.
Треба робити просто все правильно, віддаючи собі звіт в тому, який сенс в кожному елементарному дії, яке ти робиш.
Ви робите, радіючи розуміння 40 відсотків всього того, що ви робите, а решта робите з міркувань відповідностей якимось ритуалам, традиціями, або просто за інерцією.
Нічого крім жахливий глючних програм такий підхід не породжує.
А використання функції ScrollWindow для цієї мети - дуже шкідлива рада. Не можна використовувати функцію ScrollWindow для скролінгу контролери на VB-формах!
-We separate their smiling faces from the rest of their body, Captain.
-That's right! We decapitate them.
VBTerminator писал (а): Хакер, Ви маєте на увазі те, що якщо форма не поміщається на екрані, то її дизайн необхідно переробляти з нуля?
Зовсім ні, я мав на увазі не це. Я мав на увазі те, що є люди, у яких підхід до коду - як до заклинання. Дуже трепетне, в першу чергу. Букву бояться зворушений. Раптом заклинання перестане працювати. Загалом, вони оперують шматками коду, моляться на працездатність цих шматків, але бояться або не хочуть або не можуть розібрати код на атоми, ніколи не меняеют його під себе, і взагалі погано розумію, що до чого. Це найгірший підхід, природно, який тільки буває.
Але кстати да, я думаю, що проблема з дизайном. Що значить вікно не поміщається на екран? Це допустимо для вікон, які відображають якийсь документ. Текст, картинку, креслення, карти. Якщо там просто контроли, то швидше за все помилка дизайну. Або віконечко з тисячею текстбоксамі. Ненавиджу! Люди перейшли від проклятих паперових форм до комп'ютерних програм, але програми робляться як і раніше так, як ніби це паперова форма, яку треба заповнити.
VBTerminator писал (а): Не розумію, навіщо? На даний момент знання коштують грошей, тим більше ці знання не є тяжким тягарем прокляття або чогось в цьому дусі.
Ну, ті знання, які є у мене, це ж пещінка в загальносвітовому океані знань. Яка різниця, була пещінка одних знань, стала пещінка інших знань. Я остаточно переконався, що сила не в знаннях, а в умінні екстремально ефективно здобувати потрібні знання.
Ну по правді я не проти знань, якщо це не заважає вашій голові. Нехай голова і пам'ять і зберігаються в ній знання будуть таким собі кешем. Постала проблема - знаємо як вирішити - чудово. Чи не знаємо як вирішити - не питання, через 10 хвилин будемо знати.
VBTerminator писал (а). і знову вбити на це купу часу?
Чому ж купу? Треба працювати над собою так, щоб отримання нових знань займало мінімальне число часу
-We separate their smiling faces from the rest of their body, Captain.
-That's right! We decapitate them.
Хакер писал (а): Люди перейшли від проклятих паперових форм до комп'ютерних програм, але програми робляться як і раніше так, як ніби це паперова форма, яку треба заповнити.
А чим це погано? Якщо робити поправку на те, що комп'ютеризація не досягнула 100%, якщо раніше поряд з комп'ютерними формами, використовуються форми і в паперовому варіанті, і якщо прикинути витрати на перенавчання людини, яка звикла заповнювати паперові форми, то рішення зробити електронні форми, які максимально будуть схожі на паперові цілком очевидно. Інша справа, коли форми використовуються тільки в елерони вигляді і спочатку під це розробляються.
Хакер писал (а): Постала проблема - знаємо як вирішити - чудово. Чи не знаємо як вирішити - не питання, через 10 хвилин будемо знати.
Ну це безпосередньо залежить від конкретного індивіда, кому то буде потрібно 10 хвилин, а комусь і доби не вистачить. І знову ж таки здатність здобувати знання залежить в т.ч. і від обсягу тих знань, які індивід вже має і забудь він 99% свого багажу знань, навряд-чи він також швидко і легко отримає нове знання. ІМХО я б сказав так, що чим більше людина знає, тим він може швидше добути нове знання. Звичайно прямолінійною залежності тут немає, але сама залежність безсумнівно є.
Боротися і шукати, знайти і переховати
Хакер писал (а): Тому що рухається вікно (створене CreateWindow), а не контрол. Контрол думає, що він залишається на старому місці. Перевір властивості Top і Left контролів після застосування ScrollWindow ..
Так це, ІМХО, і є стандартний підхід до прокручування - "рухати контейнер, а не контроли", як alibek написав. І, наскільки я зрозумів, у ТС саме таке завдання і стоїть. А якщо сторонній контрол зринаючі підказки малює в екранних координатах, а не в клієнтських - це його (контрола) проблема - фтопку такі контроли.
Kekir писал (а): Як зробити так, щоб при зменшенні розміру вікна не тікав бігунок дуже далеко? Тобто при стандартно відкритому вікні все нормально крутиться, але варто поміняти розмір вікна, як scroll можна засунути на дуже велике значення вниз \ вліво.
І ще залишається слід, як від нього позбутися? Перемальовування за допомогою refresh не допомогла. Вона просто форму перемальовує, але не оновлює.
Не понял про слід та ін. Нарив тут свій древній приклад
ark, ти гониш по страшному.
Причому тут контейнери і які приносить елементи.
Є віконна підсистема, за яку відповідає User32, об'єктами дії якої є вікна (windows), що мають хендла, і мають свої закони життя.
Є підсистема контролів, надбудовані над підсистемою вікон. Об'єктами цієї підсистеми є COM-контроли, мають свої закони життя.
VB, ясна річ, використовує концепцію контролів, побудовану над вікнами.
Контролери влаштовані так, що при зверненні наприклад, до властивості Top контрола, реалізація контрола сама рухає відповідний контроль вікно.
ScrollWindow діє в обхід контролів і рухає самі вікна. У той час як контроли не здогадуються, що їх вікна були зрушені.
Іншими словами Command1.Top і Command1.Left до виклику ScrollWindow і після виклику ScrollWindow повернуть однакові результати, хоча сама кнопка візуально зрушиться. Тому що реалізація контрол-класу CommandButton не припускає, що кнопку-як-вікно рухалися в обхід кнопки-як-контрола.
-We separate their smiling faces from the rest of their body, Captain.
-That's right! We decapitate them.
Хакер писал (а): Іншими словами Command1.Top і Command1.Left до виклику ScrollWindow і після виклику ScrollWindow повернуть однакові результати
Ну так. Клієнтські координати і повинні залишатися однаковими. Ти приклад подивися - я рухаю вікно scrollbar'ом - в цьому випадку вся концепція screen / client зберігається.
Додано: пардон, знаючи Вашу вимогливість до точності, що не ВІКНО, а його клієнтську частину
ark писал (а): Ну да. Клієнтські координати і повинні залишатися однаковими.
Клієнтські координати чого?
-We separate their smiling faces from the rest of their body, Captain.
-That's right! We decapitate them.