Author |
Topic: MULTIWIN issues (Read 591 times) |
|
hellomike
Junior Member
member is offline
Gender: 
Posts: 55
|
 |
Re: MULTIWIN issues
« Reply #4 on: Mar 6th, 2017, 12:02pm » |
|
Nicely explained.
Ok, I will use *FONT to have better control.
However only after reading a CSV file, I know how many lines of data need to be displayed and how wide the lines will be.
Assuming that I use "Courier New,16,B" as font, how can I resize the default @hwnd% to the size I need, without using VDU 23,22?
The size of additional output windows I specify with FN_createwin().
I guess I first do *FONT and use @vdu%!216 and @vdu%!220 to calculate width and height that I need in VDU 23,22 immediately followed by PROC_multiwin(0).
Mike
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: MULTIWIN issues
« Reply #5 on: Mar 6th, 2017, 1:46pm » |
|
on Mar 6th, 2017, 12:02pm, hellomike wrote:| However only after reading a CSV file, I know how many lines of data need to be displayed and how wide the lines will be. |
|
It's non-standard to determine the size of the font from the amount of data to be displayed. The way things work, as a rule, is that the size of font is determined by legibility considerations. Then, if the data doesn't fully fit the window (or screen etc.) with that size of font, some means of dealing with that needs to be incorporated (e.g. scrolling or paging).
As I am sure you know, I am very concerned about 'accessibility', that is writing programs in such a way that they can be used by people with disabilities. Poor eyesight is probably one of the most common impairments that you need to take account of. So for example if the user has configured his PC for 'large fonts' (which corresponds to the DPI value being increased) your program(s) should respect that setting. In some jurisdictions it is actually a legal requirement that you should make 'reasonable adjustments' to meet the needs of the disabled.
Of course if your program is designed for personal use only you are not bound by such constraints. In that case you can do anything you like, such as adjust the size of the text to fit the amount of data. That can also be an appropriate thing to do in the case of (say) the title page of a video game. In such a situation it is acceptable to set the font to an absolute size in pixels rather than a size which is related to the DPI value (which is the default in BB4W and most other Windows applications). But since Windows may not be able to create a font with precisely the dimensions you specify, you still need to cope with some variability.
I should add that things get more complicated if you are writing cross-platform code. Operating Systems other than Windows may not provide system-wide means for the user to adjust the font size, or at least not in a compatible way. For example in BBCSDL the *FONT command does not take account of the DPI value, since although that would be possible in Windows, the other supported platforms don't all provide an equivalent capability.
In BBCSDL, when used with a touchscreen at least, I have attempted to address that issue to some degree by making provision for the output to be zoomed and panned without any extra effort by the BASIC programmer.
Richard.
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: MULTIWIN issues
« Reply #6 on: Mar 8th, 2017, 07:39am » |
|
Thanks for the insight. Lucky for me, the final program to be, will be for personal use only but your input makes me more aware of the do's and dont's.
I might have found another undocumented issue for programmers to consider.
When calling FN_createwin(), make sure the main output window is the active one. So, as for PROC_closewin(), if necessary precede the FN_createwin() statement with a PROC_selectwin(0).
Failing to do this will cause a new window to be a child of the wrong active window which may result in erratic behavior.
Mike
|
|
Logged
|
|
|
|
|
