mIRC Home    About    Download    Register    News    Help

Print Thread
"window -t @win NewTabStopNumber" #262298 18/01/18 02:26 AM
Joined: Jan 2004
Posts: 1,558
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,558
"window -t @win NewTabStopNumber" doesn't always work change unless the @win is a -l listbox

This is an update on the bug I was reporting here: https://forums.mirc.com/ubbthreads.php/topics/262241/Re:_window_-t_@test_does_nothi#Post262241

To reproduce:
1. create the tabbed window with: /TabTestSetup
2. use up-arrow to repeatedly run: /tabtest
This changes the tab setting with "/window -t @win $rand(10,30)" and should make the green line's tabstops change. After repeating this a few times at short intervals, it stop working. It helps to make another window active and type /tabtest there, but it soon stops working there too. Sometimes double-clicking a few times in @win finally gets the tabs to move.
3. if i remove the semi-colon in front of 'rline' and repeat #2, it's much more likely to work, but still not 100%
4. if i create the window using -el instead of -e, /tabtest immediately updates the tabs 100% of the time

This happens in the current beta, but since this feature has been around for a long time, I tried to reproduce the bad behavior in 6.35 and was unable.

Code:
alias TabTestSetup {
  window -c @win
  window -e @win 0 0 999 299 Fixedsys 9
  aline 2 @win $regsubex($str(x,100),/x/g,$right(\n,1))
  aline 3 @win $regsubex($str(x,10),/x/g,$calc(\n -1) $+ $chr(9))
  aline @win -------
}
alias TabTest {
  :label
  var %i $rand(10,30) | if (%i == %tab) goto label
  set %tab $v1
  window -t @win %tab
  ;rline @win 3 %tab
}

Re: "window -t @win NewTabStopNumber" [Re: maroon] #262302 18/01/18 07:51 PM
Joined: Jan 2004
Posts: 1,558
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,558
Just clarifying my original post. By "doesn't always work change" and "stops working", I mean that the display didn't respond to changing the tabstop with "/window -t @win NewNumber". It would eventually react to the commands after double-clicking in the window, or writing to the window with /aline /rline or or /echo, or by changing to a different editbox to continue repeating /tabtest. When the window was created using the -l switch, I wouldn't need to do any of the other things, as it would immediately change the tabstops in the display.

Re: "window -t @win NewTabStopNumber" [Re: maroon] #262305 19/01/18 10:08 AM
Joined: Dec 2002
Posts: 4,898
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,898
Thanks this issue has been fixed for the next version.

Re: "window -t @win NewTabStopNumber" [Re: Khaled] #262309 19/01/18 02:58 PM
Joined: Jul 2013
Posts: 27
K
kikuchi Offline
Ameglian cow
Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
Hello, visually speaking this issue with /window -t is the same as what I was reporting there: https://forums.mirc.com/ubbthreads.php/topics/260926/Font_rendering#Post260926
Typing /tabtest won't apply the change immediately but whenever I select the text in the window, it shows the correct tabstops/display (and eventually it ends up displaying the correct tabstop for good, even without selecting, after changing focus or similar events as to what maroon said)
Quote:

mIRC also bitmap caches some displayed text for speed, which is updated in certain contexts, which may be what you are seeing. mIRC clears this cache when fonts change, however it sounds like it is not doing it in the specific situation you are seeing. If you can provide a step by step method that reproduces this, I will try to reproduce/fix it.


I was hoping this window -t issue was just a more direct way to illustate my problem, am I wrong hoping this fix is going to resolve my issue as well (I am still experiencing my issue very often)?