From Newsgroup: comp.sys.apple2

Once upon a time, Windows remembered the last position and size of the main CiderPress window. This apparently changed some time ago, and Windows now uses a default behavior that tries to make the window cover most of the current display.
This is annoying, but a little hard to work around with the way the program is currently structured. I tweaked it to make the window 1150x800. I didn't limit it based on the display metrics, on the assumption that nobody runs at 1024x768 anymore, though this might be a bad assumption for virtual machines. I figured I'd try this and see if it was a problem for anyone.
A full solution would use the more modern window placement code, which correctly handles situations with multiple monitors. (If you just blindly save and restore the previous position and size, you can have some unpleasant surprises if displays have been removed from a multi-monitor system.) I use this in SourceGen and it seems to work well.
Right now CiderPress reads its settings from the Registry, and does so after the window placement is already determined, so it's a little awkward to restore the window metrics. My goal is to stop using the Registry to hold settings, which will make various things simpler, but requires rearranging some code. Because this will require some OS-specific testing, this will likely be the point where I drop support for WinXP. Doing so will reduce the size of the distribution dramatically since I won't have to pack in the MFC-for-WinXP compatibility DLLs, and I can stop using the VS2013 tools for builds.
cf. https://github.com/fadden/ciderpress/issues/41
Release: https://github.com/fadden/ciderpress/releases/tag/v4.0.5-d2
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

As long as it still works under Wine. My windows box is deprecated, and is really only for the ROM burner, ADT and the 6502bench disassembler. I'm not sure what extra you might gain from a bigger window, I seldom full screen anything. The 1024 by 768 window, or whatever Ciderpress opens up to, seems big enough.
The Windows box is running a 4:3 monitor at 1280 X 1024, the default setting.

Release: https://github.com/fadden/ciderpress/releases/tag/v4.0.5-d2

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

On Apr 20, 2021, Mike Spangler wrote
(in article<b6919898-335d-447c-9f31-501cbdf4849dn@googlegroups.com>):

As long as it still works under Wine. My windows box is deprecated, and is really only for the ROM burner, ADT and the 6502bench disassembler. I'm not sure what extra you might gain from a bigger window, I seldom full screen anything. The 1024 by 768 window, or whatever Ciderpress opens up to, seems big enough.

The Windows box is running a 4:3 monitor at 1280 X 1024, the default setting.

Release: https://github.com/fadden/ciderpress/releases/tag/v4.0.5-d2

As long it works for Mike and his 1280x1024 ancient hardware.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

You do realize the irony about complaining about ancient hardware on a newsgroup devoted to [drum roll] ancient hardware.
Just for the record, the Linux box is from late 2019 with a Ryzen 3200G processor, and the laptop is an M1 Macbook Air. The Windows box is from 2014 with an i5-4570-R. Intel screwed up and put decent integrated graphics on a CPU. The oldest machine I have is a unenhanced IIe.

As long it works for Mike and his 1280x1024 ancient hardware.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

yabiteme wrote:

As long it works for Mike and his 1280x1024 ancient hardware.

He's not alone. I'm (temporarily) running 1024x768. :o

Even on larger screens, i generally run things in windows much smaller
than the screen. I typically run CiderPress 4.0.4 (under Wine) at its
760x495 default, and occasionally stretch it to 901 pixels wide--which
shows the full width of the list. 1150x800 seems excessive to me.

I don't know what all is at play (hi-dpi, fonts, etc); but perhaps
geometry could optionally be specified at the command-line, or other
user controllable method.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

I reverted the change and released v4.0.5. This will be the last version that's expected to work with WinXP.

1150 is useful if you're looking at the CD-ROMs, which have some pretty deep hierarchies.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

On Sunday, April 25, 2021 at 10:11:07 AM UTC-7, fadden wrote:

I reverted the change and released v4.0.5. This will be the last version that's expected to work with WinXP.

v4.1.0-d1 saves and restores the window placement. Seems to work correctly on Win7/Win10, properly tracking the position even when the window is maximized, and repositioning the window when the monitor it was previously on has disappeared.
--- Synchronet 3.18b-Win32 NewsLink 1.113