Leaderboard

I say fake it 'till you make it Edit: ..thinking about this, it could be turned into a UDF ( not by me right now ) and it'd be good to have.

Hey all! So with the recent vscode version updates i noticed terrible performance when working with my extension. I tracked down the reason to how my extension tries to open git URI's when viewing changes via the git diff view in vscode, triggering GIT to go crazy for some reason. I looked at the latest couple of vscode release notes and could not see something that could cause this, so maybe this has always been an issue, but only for certain repositories i own affect it this way? New or old problem, I seem to have found the issue, and will deploy a fix later today. Because this problem basically forces me to reload my vscode every time it does this, I need to release this fix FAST, so smaller bugs may occur, if so, let me know I will post again, after the release with the fix is out!

imho there's something wrong in the function _GUICtrlStatusBar_SetParts found in the include file GuiStatusBar.au3 Gary Frost forces the last part of the status bar to have a value of -1, even if the user explicitely indicates another value, for example : User in script... Local $aParts[3] = [75, 150, 230] ...becomes in UDF Local $aParts[3] = [75, 150, -1] Here are the results below : The picture on the right is what the user wants (better display of the last Part 2) and not what the UDF forces us to display. msdn never wrote that the last parameter must be -1, here is what we can read on msdn's site : If an element is -1, the right edge of the corresponding part extends to the border of the window. It's written "IF", not "it must be -1 and you have to use all the window width for your status bar" For what it's worth...

A new functionality has been added to my 2nd script (found on previous page) Now all parts of the status bar got a flexible width during resizing : On the left side of the image above, the status bar parts show (on purpose) too long texts... which won't be a problem after we resize the GUI You'll notice 2 GUI's on the right side of the image above : 1) One got a visible border around the status bar parts 2) The 2nd one doesn't have borders : just pick the line of code you prefer in the script : _GUICtrlStatusBar_SetText($g_hStatus, "", $i, $SBT_OWNERDRAW) ; _GUICtrlStatusBar_SetText($g_hStatus, "", $i, $SBT_OWNERDRAW + $SBT_NOBORDERS) ; interesting ? Also, I added this test... If _GUICtrlStatusBar_IsSimple($g_hStatus) Then _GUICtrlStatusBar_Resize($g_hStatus) Else ... EndIf ...because maybe someone will use the script with a simple status bar ("simple" = no parts) just for the color change. Without the test, a normal fatal error would happen. The test on a simple status bar has been done, it seems correct, fingers crossed

With @KaFu's help in his post, adapted to our script : #include <GUIConstantsEx.au3> #include <GuiStatusBar.au3> #include <WinAPIGdi.au3> #include <WinAPIRes.au3> #include <WinAPISysWin.au3> #include <WinAPITheme.au3> #include <WindowsConstants.au3> Opt("MustDeclareVars", 1) Global $g_hGui, $g_hSizebox, $g_hOldProc, $g_hBrush, $g_hStatus, $g_iHeight, $g_aText, $g_aRatioW, $g_iBkColor, $g_iTextColor Example() ;============================================== Func Example() Local Const $SBS_SIZEBOX = 0x08, $SBS_SIZEGRIP = 0x10 Local $iW = 300, $iH = 100 Dim $g_iBkColor = 0x808080, $g_iTextColor = 0xFFFFFF $g_hGui = GUICreate("Resize corner", $iW, $iH, -1, -1, $WS_OVERLAPPEDWINDOW) GUISetBkColor($g_iBkColor) ;----------------- ; Create a sizebox window (Scrollbar class) BEFORE creating the StatusBar control $g_hSizebox = _WinAPI_CreateWindowEx(0, "Scrollbar", "", $WS_CHILD + $WS_VISIBLE + $SBS_SIZEBOX, _ 0, 0, 0, 0, $g_hGui) ; $SBS_SIZEBOX or $SBS_SIZEGRIP ; Subclass the sizebox (by changing the window procedure associated with the Scrollbar class) Local $hProc = DllCallbackRegister('ScrollbarProc', 'lresult', 'hwnd;uint;wparam;lparam') $g_hOldProc = _WinAPI_SetWindowLong($g_hSizebox, $GWL_WNDPROC, DllCallbackGetPtr($hProc)) Local $hCursor = _WinAPI_LoadCursor(0, $OCR_SIZENWSE) _WinAPI_SetClassLongEx($g_hSizebox, -12, $hCursor) ; $GCL_HCURSOR = -12 $g_hBrush = _WinAPI_CreateSolidBrush($g_iBkColor) ;----------------- $g_hStatus = _GUICtrlStatusBar_Create($g_hGui, -1, "", $WS_CLIPSIBLINGS) ; ClipSiblings style +++ Local $aParts[3] = [90, 180, -1] _GUICtrlStatusBar_SetParts($g_hStatus, $aParts) Dim $g_aText[Ubound($aParts)] = ["Part 0", "Part 1", "Part 2"] Dim $g_aRatioW[Ubound($aParts)] For $i = 0 To UBound($g_aText) - 1 _GUICtrlStatusBar_SetText($g_hStatus, "", $i, $SBT_OWNERDRAW) ; _GUICtrlStatusBar_SetText($g_hStatus, "", $i, $SBT_OWNERDRAW + $SBT_NOBORDERS) ; interesting ? $g_aRatioW[$i] = $aParts[$i] / $iW Next Local $idChangeText = GUICtrlCreateButton("Change Text", 110, 25, 80, 30), $iInc GUICtrlSetResizing(-1, $GUI_DOCKHEIGHT) ; to allow the setting of StatusBar BkColor at least under Windows 10 _WinAPI_SetWindowTheme($g_hStatus, "", "") ; Set status bar background color _GUICtrlStatusBar_SetBkColor($g_hStatus, $g_iBkColor) $g_iHeight = _GUICtrlStatusBar_GetHeight($g_hStatus) + 3 ; change the constant (+3) if necessary GUIRegisterMsg($WM_SIZE, "WM_SIZE") GUIRegisterMsg($WM_DRAWITEM, "WM_DRAWITEM") GUISetState() While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $idChangeText $iInc += 1 For $i = 0 To UBound($g_aText) - 1 $g_aText[$i] = "Part " & $i & " : Inc " & $iInc Next _WinAPI_RedrawWindow($g_hStatus) EndSwitch WEnd _GUICtrlStatusBar_Destroy($g_hStatus) _WinAPI_DeleteObject($g_hBrush) _WinAPI_DestroyCursor($hCursor) _WinAPI_SetWindowLong($g_hSizebox, $GWL_WNDPROC, $g_hOldProc) DllCallbackFree($hProc) GUIDelete($g_hGui) EndFunc ;==>Example ;============================================== Func ScrollbarProc($hWnd, $iMsg, $wParam, $lParam) ; Andreik If $hWnd = $g_hSizebox Then Switch $iMsg Case $WM_ERASEBKGND Local $tRect = _WinAPI_GetClientRect($hWnd) _WinAPI_FillRect($wParam, $tRect, $g_hBrush) Return True Case $WM_PAINT Local $tPAINTSTRUCT Local $hDC = _WinAPI_BeginPaint($hWnd, $tPAINTSTRUCT) Local $tRect = _WinAPI_CreateRect($tPAINTSTRUCT.Left, $tPAINTSTRUCT.Top, $tPAINTSTRUCT.Right, $tPAINTSTRUCT.Bottom) _WinAPI_FillRect($hDC, $tRect, $g_hBrush) _WinAPI_EndPaint($hWnd, $tPAINTSTRUCT) Return 0 EndSwitch EndIf Return _WinAPI_CallWindowProc($g_hOldProc, $hWnd, $iMsg, $wParam, $lParam) EndFunc ;==>ScrollbarProc ;============================================== Func WM_SIZE($hWnd, $iMsg, $wParam, $lParam) ; Pixelsearch #forceref $iMsg, $wParam, $lParam If $hWnd = $g_hGUI Then Local $aSize = WinGetClientSize($g_hGui) If _GUICtrlStatusBar_IsSimple($g_hStatus) Then _GUICtrlStatusBar_Resize($g_hStatus) Else Local $aGetParts = _GUICtrlStatusBar_GetParts($g_hStatus) Local $aParts[$aGetParts[0]] For $i = 0 To $aGetParts[0] - 2 $aParts[$i] = Int($aSize[0] * $g_aRatioW[$i]) Next $aParts[$aGetParts[0] - 1] = -1 _GUICtrlStatusBar_SetParts($g_hStatus, $aParts) EndIf WinMove($g_hSizebox, "", $aSize[0] - $g_iHeight, $aSize[1] - $g_iHeight, $g_iHeight, $g_iHeight) _WinAPI_ShowWindow($g_hSizebox, (BitAND(WinGetState($g_hGui), $WIN_STATE_MAXIMIZED) ? @SW_HIDE : @SW_SHOW)) EndIf Return $GUI_RUNDEFMSG EndFunc ;==>WM_SIZE ;============================================== Func WM_DRAWITEM($hWnd, $iMsg, $wParam, $lParam) ; Kafu #forceref $hWnd, $iMsg, $wParam Local $tDRAWITEMSTRUCT = DllStructCreate("uint CtlType;uint CtlID;uint itemID;uint itemAction;uint itemState;HWND hwndItem;HANDLE hDC;long rcItem[4];ULONG_PTR itemData", $lParam) If $tDRAWITEMSTRUCT.hwndItem <> $g_hStatus Then Return $GUI_RUNDEFMSG ; only process the statusbar Local $itemID = $tDRAWITEMSTRUCT.itemID ; status bar part number (0, 1, ...) Local $hDC = $tDRAWITEMSTRUCT.hDC Local $tRect = DllStructCreate("long left;long top;long right; long bottom", DllStructGetPtr($tDRAWITEMSTRUCT, "rcItem")) Local $iTop = $tRect.top, $iLeft = $tRect.left Local $hBrush = _WinAPI_CreateSolidBrush($g_iBkColor) ; backgound color _WinAPI_FillRect($hDC, DllStructGetPtr($tRect), $hBrush) _WinAPI_SetTextColor($hDC, $g_iTextColor) ; text color _WinAPI_SetBkMode($hDC, $TRANSPARENT) DllStructSetData($tRect, "top", $iTop + 1) DllStructSetData($tRect, "left", $iLeft + 1) _WinAPI_DrawText($hDC, $g_aText[$itemID], $tRect, $DT_LEFT) _WinAPI_DeleteObject($hBrush) $tDRAWITEMSTRUCT = 0 Return $GUI_RUNDEFMSG EndFunc ;==>WM_DRAWITEM

that's what I would answer.

Both of these are nice features to have. I got a chance to test these this morning and it's working great. And the addition of the expanding status bar parts is wonderful and important. In my opinion, after testing every possible option over several days, I honestly think that the best possible UI/UX experience is a combination of real status bar and fake. Your script offers removing the terrible looking old-style grip, while @argumentum's script could use a fake status bar (label) with those beautiful modern squares added as a grip. If you could somehow add those squares over your blank space, that would be the icing on the cake. At least as an option, anyway. I spent some more time this morning trying to combine the two but failed again. It's beyond my skills. This is quite an interesting find. It would be nice to be able to specify what you want for the third part size without it being forced to -1. I suppose that would require adding a fixed version of the _GUICtrlStatusBar_SetParts function to your script.

That is absolutely perfect. Thank you. This fix might actually be beneficial for the following suggestion as well: If possible, I think that it would be best to incorporate the example script that @water suggested which adds the appearance of gripper dots in the bottom corner. This, of course, would be hidden when maximized. The gripper dots would have to scaling according to status bar height which the example does not have. I tried my best to combine that feature from the script into your script for about an hour but failed miserably. I don't understand how it works so therefore all of my attempts were just guessing.

Ok we're back with a new stuff in post #1. You'll first need to compile "playerDemo_engine.au3", then run "playerDemo.au3". We're still using a modal to block execution in the engine script - wish we could do something nicer, but I guess it'll have to do for now. For comms between processes we're using windows messages (thanks nine for the inspiration!). Look for the $WM_ME* values in the constants file. The WM codes are the same values as those generated by the mediaengine, combined with WM_APP. There's one totally "made up" code - its for MediaEngine to send through its window handle to the UI process ($WM_ME_PLAYBACKWINDOW). Also with the WMs, there's a bit of jiggery pokey in order to pass floating point values over wparam and lparam. I found if you send values as a float or double, they pop out as an integer on the other end - so you lose everything after the decimal point. But sending the values as binary solves this. We just need to ensure we convert our "doubles" to "floats" for x86 so the values fit within wparam/lparam. One last thing... you can still crash the engine by flooding it with messages from the UI, but that's where we're at for now. We could probably fix this by only check incoming messages from within the event handler... Then the problem is the engine won't be contactable when its paused, so you'd need to flick between two modes of checking for messages. And it would also require a total rethink of how to pass comms from the UI back to the engine!