[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: New Windows installer for vDos-lfn



Hi Kari,

Thanks for your message.

Regarding the settings of KEYDELAY and KEYINTER, in theory you can change their values to whatever you want. Unlike in vDosXy, which simply changes the default settings of these values, in vDos-lfn I had to implement a timer to achieve this feature. Thus, from the implementation view there are only two options: 1. to use the Windows settings, and 2. to use the values specified by KEYDELAY and KEYINTER. Thus, KEYDELAY=400 and KEYDELAY=500 should really make no difference (except the actually delay), at least in theory. And indeed, I am still not able to reproduce the problem you described when I change KEYDELAY=400 to KEYDELAY=500, no matter what I try.

Regarding multiple screen support. This is actually my first time to experience with multiple screens, so it is rather new, and I had spent a few hours today to get multiple screen work and to experience with it. However, by looking at the code of vDos, I have realized that it is not quite straightforward to implement full multiple screen support. Currently, vDos simply calls a Windows API to get the handler to the current monitor, and use that handler to achieve its fullscreen feature. It is quite a different story if you want to actually specify a monitor to use. If you want to open the vDos-lfn window on a certain monitor, a solution is to move the vDos-lfn window to the monitor you want, and then close it. The next time you run vDos-lfn, it will be opened in that monitor. I might try to add the feature to specify a monitor to use later.

The situation you mentioned about Ctrl drag is also on multiple screens. However, I have not yet been able to produce the crash as you described. For example, the resolution of my primary screen is 1366*768, and I set the resolution of the secondary screen to be 800*600. Then I made a rather big vDos-lfn window on the first screen, and then move it into the second screen. The window was bigger than the second screen, but when I made it full screen it did not crash. So I guess there must be some conditions which must be met in order for the crash to happen.

Regarding the taskbar, I have noticed that the vDos screen is not the topmost screen, so it can be hidden by the Windows taskbar when they overlap. In order to solve this problem, I decided to add an option to vDos-lfn's config.txt. Now you can set "TOPWIN=ON" in config.txt so that the vDos-lfn window will always be the topmost window when it is active. As usual I have updated the vDos-lfn binary and installer. Please download the latest version.

Wengier


On Sunday, May 15, 2016 9:01 AM, Kari Eveli wrote:


Hi Wengier,

Thanks for sorting these things out. The progress has been outstanding
so far.

I had 'KEYDELAY = 500', and when I changed this to 400, the problem
disappeared. Is there an allowable range for these values (KEYDELAY and
KEYINTER) ?

The Ctrl drag solution works well. There is, however, a situation that
causes the app to crash. If you move the application window to another
screen (and the window is so big that it does not fit completely into
the new screen because of resolution) and try to make it full screen, it
crashes. Most virtual machines I use calculate the percentage of screen
area the app window occupies, and open the maximized app window on the
screen with the biggest percentage of overlap.

I would also like renew my question about multiple screen support.
Clearly, the app is aware of the screen it is on, so would it be
possible to make it open on a certain screen via config.txt? E.g. SCREEN = 2

Another minor observation regarding the taskbar. When you open the app
on a screen with a Windows taskbar and the application window is so big
that it overlaps the taskbar, the app window is not topmost if it is not
full screen. You can only make all of the application window show if you
make it full screen. You can then normalize the window (alt-enter) and
it retains full view, but only until the next switch to some other
application. Then you would need to repeat the maximize cycle to have
full view. (Taskbar behavior is different on different versions of
Windows, I am running Win 7).

Best regards,

Kari Eveli
LEXITEC Book Publishing (Finland)
lexitec@xxxxxxxx

*** Lexitec Online ***
Lexitec in English: http://www.lexitec.fi/english.html
Home page in Finnish: http://www.lexitec.fi/

14.5.2016, 16:08, Wengier W (Redacted sender wengierwu for DMARC) wrote:
> Regarding the PgUp or PgDn key, may I ask when the behavior as you
> described occurs? I tried PgUp/PgDn for scrolling in QBASIC for
> example, and they seem to work fine with either KEYMODE=1 or
> KEYMODE=2. I also tried to redefine PgUp and PgDn keys (e.g. to "+"
> and "-" respectively) in XyWrite 3, and the customized keys seem to
> work fine too. It will be better if you can describe the issue you had
> encountered more clearly. Thanks!