Messages - mackal [ switch to compact view ]

Pages: prev1 2 3 [4] 5next
16
FARR Plugins and Aliases / Re: New FARR Plugin: FCalc
« on: August 23, 2007, 10:54 AM »
This is a cool plugin, but could seriously use a pair of functions, say deg() and rad(), for converting between degrees and radians.  The trig functions assume that the arguments are in radians, whereas most quick calculations with FARR are bound to involve degrees (unless you're a mathie or doing math homework  ;) ).  So then we could type in "fc sin(rad(90))", for example.  Or perhaps the trig functions could be adapted to take degrees instead...

17
Find And Run Robot / Re: Custom Font Settings for FARR
« on: August 23, 2007, 03:07 AM »
Hi all,

I am having the same problem that tablaji was having with the clipped icons.  My DPI is set to "Normal 96" in Control Panel > Display > Settings > Advanced, and I am using Display Settings > Appearance > Effects > "Use large icons" option in Windows, since otherwise things are just way too tiny on my laptop (1680x1050 resolution).  But my explorer icon sizes look the same as in jgpaiva's screenshot, so I do not think I have "unusual" settings.  Can FARR be made to work with my setup?

EDIT: actually a few more observations:
  • if I turn off "Use large icons" and restart FARR, FARR's "large icons" work/look great!  (but need a microscope to use the icons on my desktop then...  :( )
  • if I then turn "Use large icons" back on, but do not restart FARR, I get the best of both worlds
  • Launchy has no problems with icon sizes, regardless what my desktop setting is

Surely this is an issue in how FARR obtains the icons, no?  If Launchy can do it...  :P  (it uses the large version of icons that are present when "Use large icons" is off, even when that setting is turned on... somehow it ignores the desktop setting and polls the correct-sized icon directly).

jgpaiva: my explorer window icon sizes match the ones in your attached pic.  Do you not have the same clipping problem when using large icons in FARR?  It sounds like you don't... I wonder what's different about my setup...

BTW, I'm using the latest beta, downloaded today.



18
ace and mackal,
so what's the verdict? does the ahk script work well yet?
when it's ready perhaps we can convince you to make a little .ahk/precompiled-exe zip file for easy download?

Well, it works well enough for me, although I've encountered the same problem as Justice, and was wondering how to implement options; but skrommel's solution sounds pretty good, I will try it out.  Other than that, I don't think I'll be babying/tweaking this script further, since it meets > 95% of my requirements.  I can put out an .ahk, but not sure how to convert to .exe...

19
Actually, it turns out that the SetWindowRedraw() approach wasn't working at all (DllCall() resulted in an ErrorLevel of -4, i.e., function not found), hence why I was so quick to dismiss your suggestion...  I've since found that DllCall("LockWindowUpdate", ...) works instead:

  http://msdn2.microsoft.com/en-us/library/ms534869.aspx

Perhaps a difference of OSes? I am using WinXP... I think this does the same thing.  Even though it freezes the client area only, it actually makes a huge difference!  Thanks for pointing me down this road, skrommel!  :up:

Updated code, for those interested:
Spoiler
fs_engaged := 0      ; is "fullscreen" engaged for some window?
padding := 2      ; additional padding width to remove, in pixels

#Enter::
if (fs_engaged = 0) {
    ID:=WinActive("A")
    hwnd:=WinExist("A")
    DllCall("LockWindowUpdate",UInt,hwnd)
    WinGetPos, oldX, oldY, oldW, oldH   ; save old dimensions
    WinSet, Style, -0xC00000, ahk_id %ID% ; remove titlebar/WS_CAPTION
    WinSet, Style, -0x40000 , ahk_id %ID% ; remove borders/WS_SIZEBOX
    WinSet, AlwaysOnTop , On, ahk_id %ID%

    ;; work out current desktop resolution
    SysGet, m, Monitor
    desk_width := mRight - mLeft
    desk_height := mBottom - mTop

    WinMove, ahk_id %ID%,, -padding,-padding
       ,desk_width+2*padding, desk_height+2*padding

    DllCall("LockWindowUpdate",UInt,0)
    fs_engaged:=1
} else {
    ;; reverse all the operations performed above
    DllCall("LockWindowUpdate",UInt,hwnd)
    WinSet, AlwaysOnTop , Off, ahk_id %ID%
    WinSet, Style, +0xC00000, ahk_id %ID%
    WinSet, Style, +0x40000 , ahk_id %ID%
    WinMove, ahk_id %ID%,, oldX,oldY, oldW,oldH
    DllCall("LockWindowUpdate",UInt,0)
    fs_engaged:=0
}
WinSet, Redraw,,%ID%   ; optimization for Vista
         ; (not sure how this interacts with the new
         ; LockWindowUpdate calls...)

return


20
:) To prevent windows repainting, have a look at these API functions:


SendMessage(hwnd, WM_SETREDRAW, FALSE, 0)
SendMessage(hwnd, WM_SETREDRAW, TRUE, 0)

or

SetWindowRedraw(hwnd, FALSE)
SetWindowRedraw(hwnd, TRUE)

Try something like
hwnd:=WinExist("A")
DllCall("SetWindowRedraw",UInt,hwnd,UInt,1)
Skrommel

If I understand this correctly, it prevents repaints to the window's client area, right?  I misworded my intention: I was wondering about getting Window's to freeze display of the WHOLE window.  Currently, I can see the window lose its border, then caption, then move and resize, all steps seperate but in quick succession; instead I would like to have the window go directly from its initial configuration to its final look DIRECTLY.  Not sure how doable it is with just AHK though...

Pages: prev1 2 3 [4] 5next
Go to full version