GrandBridge (3 онлайн)
- Автор темы Dmitry Stepin
- Дата начала
Тогда еще вопрос. А 32-ух битные инструменты как правильно открывать? В какую папку их поставить и как указать ее этому замечательному плагину?
Не так , наоборот AOT включен должен быть , тогда можно закрывать родительское окно ) а плагин будет висеть) но в последнем билде
эта функция была отключена , включил ))
поведение там такое (по умолчанию ) , без AOT - дочернее окно жестко привязано к поведению родительского ...
эта функция была отключена , включил ))
поведение там такое (по умолчанию ) , без AOT - дочернее окно жестко привязано к поведению родительского ...
Последнее редактирование:
пробовал в рипере 3 плагина, voxciter и органчики из соседней темы, voxciter работает норм.
органчики нет...
- bug1 - увеличил плагин, на экране 27 кнопки реагирую норм, перекинул на 24 - прицел слетел, наводишь на одну кнопку, нажимается другая, то же с фэйдерами и кнопками..
- bug2 - выключил Zoom, пытаюсь передвинуть плагин с экрана 27 на 24, окошко плагина зависает и дёргается ... помогает ctr+shift-esc - окно плагина возвращается на основной экран.
- проверил ещё с softube british class a, то же самое при передвигании с 27 на 24,
но если включён Zoom - передвигается нормально, но тогда прицел сбит, в кнопки не попадает
видео: (первое с кнопками не проигрывается, но можно скачать )
вот такой баг-репорт
Последнее редактирование:
evgeny26
Ну логично , потому что текущий зум расчитан на один фиксированный DPI) тоже вопрос , фиксить или нет , особенно когда не на чем проверить .. или написать , unsporrted) типа зум тока на основном мониторе
хотя пофиксить в принципе можно , надо чтобы при переносе невидимое окно основного плагина , получало данные о новом DPI)
но там могут быть проблем куча тоже
ну насчёт Zoom понятно, это как бы опционально,
а вот почему окно плагина без зума зависает при передвижении, интересный вопрос.. раскидать плагины по экранам, думаю многие так делают
Why Does It Only Happen 27" → 24"?
Imagine this scenario (common with 27" 2560×1440 and 24" 1920×1080):- You drag the plugin window to the edge of the 27" screen.
- The window partially crosses to the 24" screen.
- Windows sends
WM_WINDOWPOSCHANGINGwith a new position (e.g., negative X coordinates, or a rect that extends beyond the smaller monitor’s bounds). - Your bridge sees this new position/size and tries to be "helpful" – perhaps it calls
SetWindowPosto clamp the plugin to the target monitor's work area, or it tries to resize the container to fit the new screen geometry. - This
SetWindowPostriggers anotherWM_WINDOWPOSCHANGINGmessage. - The bridge processes it again, clamps again, calls
SetWindowPosagain... - This creates a rapid feedback loop that manifests as shaking/hanging.
Because moving to a larger resolution monitor doesn't require clamping. The window naturally fits, so your bridge doesn't interfere, and the loop never starts.
How to Detect This Issue in Your Bridge Code
Add logging to these specific Windows messages. This will confirm the feedback loop:cpp
case WM_WINDOWPOSCHANGING:
{
WINDOWPOS* wp = (WINDOWPOS*)lParam;
// Log wp->x, wp->y, wp->cx, wp->cy
// If you see this message firing repeatedly without the mouse moving, you have a loop.
break;
}
case WM_GETMINMAXINFO:
{
// Log the ptMinTrackSize and ptMaxTrackSize
// If these values change rapidly, your bridge is fighting the plugin.
break;
}
The Fix: Stop Resizing During Movement
The golden rule for plugin bridges is:Your bridge's container window should only handle its own position during a drag. The embedded plugin's size should remain completely untouched while the mouse is moving.
Implement this logic:
cpp
// In your bridge's window procedure
case WM_ENTERSIZEMOVE:
// User started dragging. Disable any automatic resizing/clamping.
m_isDragging = true;
break;
case WM_EXITSIZEMOVE:
// User released the mouse. Now you can safely clamp the position
// or adjust the plugin if needed, but do it ONCE.
m_isDragging = false;
ClampWindowToVisibleArea(); // Call this only once!
break;
case WM_WINDOWPOSCHANGING:
{
if (m_isDragging)
{
// DO NOT call SetWindowPos or modify wp->cx/wp->cy here.
// Let the user drag freely. Let Windows handle the movement.
break;
}
// Only handle resizing logic when the mouse is NOT dragging.
break;
}
By doing nothing during the drag, the window moves smoothly. When the user releases the mouse (
WM_EXITSIZEMOVE), you can safely adjust the position or size once, which will not cause a loop.Fix for WM_GETMINMAXINFO
Sometimes, the plugin imposes a minimum size that is larger than what the 24" monitor's work area can fully contain. Your bridge might be setting a maximum size in WM_GETMINMAXINFO to keep the window on screen.The fix: In
WM_GETMINMAXINFO, do not restrict the maximum size based on the current monitor's resolution unless the window is being sized by the user. If the plugin demands 1200×800 and the 24" screen is 1920×1080, it will still fit, so no restriction is needed. Only clamp positions, not sizes.Can You Detect This at Scan Time?
No, you cannot reliably detect this at scan time. The shaking only occurs due to the interaction between your bridge's window procedure, the plugin's internal UI thread, and the specific monitor geometry. It is a runtime state issue, not a static property of the plugin's binary.However, you can add a runtime safeguard in your bridge:
cpp
// Track the last time WM_WINDOWPOSCHANGING was called
static DWORD lastCallTime = 0;
DWORD currentTime = GetTickCount();
case WM_WINDOWPOSCHANGING:
{
// If this message is being called more than 30 times per second
// while the mouse isn't moving, break the loop.
if (currentTime - lastCallTime < 10) // Less than 10ms between calls
{
// We're in a loop. Immediately return without processing.
return 0;
}
lastCallTime = currentTime;
break;
}
This acts as a circuit-breaker, stopping the shaking even if your logic accidentally causes a feedback loop.
Summary of Actions
[th]
[td]Bridge resizes plugin during drag[/td][td]Block all Problem
[/th][th]Fix
[/th]SetWindowPos calls while WM_ENTERSIZEMOVE is active. Only act on WM_EXITSIZEMOVE.[/td]
[td]Feedback loop in WM_WINDOWPOSCHANGING[/td][td]Never call SetWindowPos from inside WM_WINDOWPOSCHANGING.[/td]
[td]Asymmetric issue (27→24 only)[/td][td]Caused by clamping logic that only activates when the destination is smaller. Defer all clamping to WM_EXITSIZEMOVE.[/td]
он ещё в процессе переделки, надеюсь завтра доделаю
а тяжёлый в смысле, долго сканирует, или грузит CPU ?
да мне базу идеи кода хотя бы , фулл код цельного не надо , хэндоффа хватит
скажи клоду "собери хэндофф по текущему билду сканера "
Еще , говорят "ии за тебя все делает " вот хер там , он может только черновую работу делать по коду и разбирать баги ) и то максимально тупо )) все надо самому придумывать ))
Идею реализации сканера незаметного ,уже придумал , не дождался) ...Жени ))
Впрочем и идею зума тоже придумал с нуля , да и все прочие идеи в плагине тоже ) ...
Это нихрена не ии ...
Идею реализации сканера незаметного ,уже придумал , не дождался) ...Жени ))
Впрочем и идею зума тоже придумал с нуля , да и все прочие идеи в плагине тоже ) ...
Это нихрена не ии ...
как раз скинул в личку
(форум чё то глючит, может и его можно отбриджить как то ?
)