aboutsummaryrefslogtreecommitdiff
path: root/windows.c (follow)
Commit message (Collapse)AuthorAge
* Replace fe->preset_menu when we change midend.Simon Tatham2018-12-12
| | | | | | | | | | | | | | | Thanks to Rocco Matano for reporting that in the -DCOMBINED version of the Windows front end, switching games causes a crash because the presets menu from the old midend is still left over in fe, and its presence inhibits the setup code from making a new one. Now we throw it out at the same time as we throw out the old midend itself. Also, the condition 'if (!fe->preset_menu)' was misguided. I think the point of that was to avoid pointlessly tearing down and rebuilding the preset menu when we're _not_ changing game - but that's a cost too small to worry about if it causes the slightest trouble. Now fe->preset_menu should always be NULL at that point in the function, so I've replaced the if with an assert.
* Use C99 bool within source modules.Simon Tatham2018-11-13
| | | | | | | | | | This is the main bulk of this boolification work, but although it's making the largest actual change, it should also be the least disruptive to anyone interacting with this code base downstream of me, because it doesn't modify any interface between modules: all the inter-module APIs were updated one by one in the previous commits. This just cleans up the code within each individual source file to use bool in place of int where I think that makes things clearer.
* Replace TRUE/FALSE with C99 true/false throughout.Simon Tatham2018-11-13
| | | | | | This commit removes the old #defines of TRUE and FALSE from puzzles.h, and does a mechanical search-and-replace throughout the code to replace them with the C99 standard lowercase spellings.
* Adopt C99 bool in the printing API.Simon Tatham2018-11-13
| | | | | | | | | | | | | | Not many changes here: the 'dotted' flag passed to print_line_dotted is bool, and so is the printing_in_colour flag passed to print_get_colour. Also ps_init() takes a bool. line_dotted is also a method in the drawing API structure, but it's not actually filled in for any non-print-oriented implementation of that API. So only front ends that do platform-specific _printing_ should need to make a corresponding change. In-tree, for example, windows.c needed a fix because it prints via Windows GDI, but gtk.c didn't have to do anything, because its CLI-based printing facility just delegates to ps.c.
* Adopt C99 bool in the midend API.Simon Tatham2018-11-13
| | | | | | | | | | | | | This changes parameters of midend_size and midend_print_puzzle, the return types of midend_process_key, midend_wants_statusbar, midend_can_format_as_text_now and midend_can_{undo,redo}, the 'bval' field in struct config_item, and finally the return type of the function pointer passed to midend_deserialise and identify_game. The last of those changes requires a corresponding fix in clients of midend_deserialise and identify_game, so in this commit I've also updated all the in-tree front ends to match. I expect downstream front ends will need to do the same when they merge this change.
* Make the code base clean under -Wwrite-strings.Simon Tatham2017-10-01
| | | | | I've also added that warning option and -Werror to the build script, so that I'll find out if I break this property in future.
* Assorted char * -> const char * API changes.Simon Tatham2017-10-01
| | | | | | I went through all the char * parameters and return values I could see in puzzles.h by eye and spotted ones that surely ought to have been const all along.
* Return error messages as 'const char *', not 'char *'.Simon Tatham2017-10-01
| | | | | They're never dynamically allocated, and are almost always string literals, so const is more appropriate.
* Use a proper union in struct config_item.Simon Tatham2017-10-01
| | | | | | This allows me to use different types for the mutable, dynamically allocated string value in a C_STRING control and the fixed constant list of option names in a C_CHOICES.
* Fix an int->pointer cast warning in windows.c.Simon Tatham2017-10-01
| | | | | | | | | | If I increase clang-cl's warning pickiness, it starts objecting to my cast to HMENU from a (potentially, in 64 bits) smaller integer type. Actually I don't think there's a problem there - all the integer ids I cast to HMENU are nice small numbers and a widening cast is just fine. But I can suppress the warning by using INT_PTR instead of int in the prototype for mkctrl, so it's easiest just to do that.
* Map Ctrl-Shift-Z to Redo.Simon Tatham2017-09-20
| | | | | | This is in addition to the existing keystrokes r, ^R and ^Y. I've become used to Ctrl-Shift-Z in other GUI games, and my fingers keep getting confused when my own puzzles don't handle it the same way.
* Generate special fake keypresses from menu options.Simon Tatham2017-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes an amusing UI bug that I think can currently only come up in the unpublished puzzle 'Group', but there's no reason why other puzzles _couldn't_ do the thing that triggers the bug, if they wanted to. Group has unusual keyboard handling, in that sometimes (when a cell is selected for input and the key in question is valid for the current puzzle size) the game's interpret_move function will eat keystrokes like 'n' and 'u' that would otherwise trigger special UI events like New Game or Undo. The bug is that fake keypress events generated from the GUI menus looked enough like those keystrokes that interpret_move would eat those too. So if you start, say, a 16x16 Group puzzle, select an empty cell, and then choose 'new game' from the menu, Group will enter 'n' into the cell instead of starting a new game! I've fixed this by inventing a new set of special keystroke values called things like UI_NEWGAME and UI_UNDO, and having the GUI menus in all my front ends generate those in place of 'n' and 'u'. So now the midend can tell the difference between 'n' on the keyboard and New Game from the menu, and so Group can treat them differently too. In fact, out of sheer overcaution, midend.c will spot keystrokes in this range and not even _pass_ them to the game back end, so Group shouldn't be able to override these special events even by mistake. One fiddly consequence is that in gtk.c I've had to rethink the menu accelerator system. I was adding visible menu accelerators to a few menu items, so that (for example) 'U' and 'R' showed up to the right of Undo and Redo in the menu. Of course this had the side effect of making them real functioning accelerators from GTK's point of view, which activate the menu item in the same way as usual, causing it to send whatever keystroke the menu item generates. In other words, whenever I entered 'n' into a cell in a large Group game, this was the route followed by even a normal 'n' originated from a real keystroke - it activated the New Game menu item by mistake, which would then send 'n' by mistake instead of starting a new game! Those mistakes cancelled each other out, but now I've fixed the latter, I've had to fix the former too or else the GTK front end would now undo all of this good work, by _always_ translating 'n' on the keyboard to UI_NEWGAME, even if the puzzle would have wanted to treat a real press of 'n' differently. So I've fixed _that_ in turn by putting those menu accelerators in a GtkAccelGroup that is never actually enabled on the main window, so the accelerator keys will be displayed in the menu but not processed by GTK's keyboard handling. (Also, while I was redoing this code, I've removed the logic in add_menu_item_with_key that reverse-engineered an ASCII value into Control and Shift modifiers plus a base key, because the only arguments to that function were fixed at compile time anyway so it's easier to just write the results of that conversion directly into the call sites; and I've added the GTK_ACCEL_LOCKED flag, in recognition of the fact that _because_ these accelerators are processed by a weird mechanism, they cannot be dynamically reconfigured by users and actually work afterwards.)
* Win64-cleanness: switch to {Get,Set}WindowLongPtr.Simon Tatham2017-08-24
|
* Rework the preset menu system to permit submenus.Simon Tatham2017-04-26
| | | | | | | | | | | | | | | | | | | | To do this, I've completely replaced the API between mid-end and front end, so any downstream front end maintainers will have to do some rewriting of their own (sorry). I've done the necessary work in all five of the front ends I keep in-tree here - Windows, GTK, OS X, Javascript/Emscripten, and Java/NestedVM - and I've done it in various different styles (as each front end found most convenient), so that should provide a variety of sample code to show downstreams how, if they should need it. I've left in the old puzzle back-end API function to return a flat list of presets, so for the moment, all the puzzle backends are unchanged apart from an extra null pointer appearing in their top-level game structure. In a future commit I'll actually use the new feature in a puzzle; perhaps in the further future it might make sense to migrate all the puzzles to the new API and stop providing back ends with two alternative ways of doing things, but this seemed like enough upheaval for one day.
* Insert a manual reference in the default status bar text.Jonas Kölker2015-10-03
| | | | | | To guide developers to the resources they need. [actual wording tweaked by SGT]
* Replace a TCHAR with a WCHAR.Simon Tatham2015-08-01
| | | | | | | | | MultiByteToWideChar expects a WCHAR[256] output buffer if you pass it an output length of 256. TCHAR[256] is entirely the wrong size, though for some reason Visual Studio seems not to have thrown a compile error pointing that out. Thanks to Jason Hood for spotting this.
* Revamp of the Windows command-line parsing and puzzle-loading code.Simon Tatham2013-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows puzzles now accept similar command-line syntax to the GTK ones, in that you can give them either a game ID (descriptive, random or just plain params) or the name of a save file. Unlike the GTK ones, however, the save file interpretation is tried first; this is because some puzzles (e.g. Black Box) will interpret any old string as a valid (if boring) game ID, and unlike the GTK puzzles it's not feasible to require users to disambiguate via a command-line option, because on Windows a thing that might easily happen is that a user passes a save file to a puzzle binary via 'Open With' in the GUI shell, where they don't get the chance to add extra options. In order to make this work sensibly in the all-in-one Windows app, I had to get round to another thing I've been planning to do for a while, which is to write a function to examine a saved game file and find out which puzzle it's for. So the combined Windows binary will auto-switch to the right game if you pass a save file on its command line, and also if you use Load while the program is running. Another utility function I needed is one to split the WinMain single command line string into argv. For this I've imported a copy of split_into_argv() from Windows PuTTY (which doesn't affect this package's list of copyright holders, since that function was all my own code anyway). [originally from svn r9749]
* Patch from James H: make the Windows debugging output conditional onSimon Tatham2010-01-12
| | | | | | an enabling environment variable. [originally from svn r8834]
* Memory leak fix from James H.Simon Tatham2010-01-07
| | | | [originally from svn r8815]
* Introduce, and implement as usefully as I can in all front ends, aSimon Tatham2009-12-27
| | | | | | | | | | new function in the drawing API which permits the display of text from outside basic ASCII. A fallback mechanism is provided so that puzzles can give a list of strings they'd like to display in order of preference and the system will return the best one it can manage; puzzles are required to cope with ASCII-only front ends. [originally from svn r8793]
* Minor bug fixes from James Harvey.Simon Tatham2009-12-17
| | | | [originally from svn r8785]
* Introduce some infrastructure to permit games' print functions toSimon Tatham2009-02-22
| | | | | | draw dotted lines. No puzzle yet uses this, but one's about to. [originally from svn r8453]
* Patch from James H to enable a single monolithic binary to be builtSimon Tatham2009-01-06
| | | | | | | | alongside the individual puzzle binaries, on Windows only. (MacOS already has it, of course; Unix would require about as much work again.) [originally from svn r8396]
* Typo spotted by James H.Simon Tatham2008-09-13
| | | | [originally from svn r8180]
* New infrastructure feature. Games are now permitted to beSimon Tatham2008-09-06
| | | | | | | | | | | | | | | | | | | | | | _conditionally_ able to format the current puzzle as text to be sent to the clipboard. For instance, if a game were to support playing on a square grid and on other kinds of grid such as hexagonal, then it might reasonably feel that only the former could be sensibly rendered in ASCII art; so it can now arrange for the "Copy" menu item to be greyed out depending on the game_params. To do this I've introduced a new backend function (can_format_as_text_now()), and renamed the existing static backend field "can_format_as_text" to "can_format_as_text_ever". The latter will cause compile errors for anyone maintaining a third-party front end; if any such person is reading this, I apologise to them for the inconvenience, but I did do it deliberately so that they'd know to update their front end. As yet, no checked-in game actually uses this feature; all current games can still either copy always or copy never. [originally from svn r8161]
* Implement tick marks in the Type menu on Windows. Now all my frontSimon Tatham2008-04-09
| | | | | | ends have got them. [originally from svn r7982]
* Revise the printing colour framework so that we can explicitlySimon Tatham2008-04-07
| | | | | | | request either of hatching or halftoning, and also choose which to supply as a fallback when printing in colour. [originally from svn r7976]
* In the Windows frontend, stop tab navigation from activating buttons.Jacob Nevins2007-03-31
| | | | [originally from svn r7436]
* r7364 failed to expand a malloc to match the larger data being putSimon Tatham2007-03-11
| | | | | | | in it. [originally from svn r7387] [r7364 == 39d299f579da3e91308d63acc78c68ab74666989]
* Since we've changed the semantics of the `expand' argument to midend_size(),Jacob Nevins2007-03-03
| | | | | | change the name. Also document the new semantics. [originally from svn r7369]
* Patch from James H to provide resizability on Windows.Simon Tatham2007-03-03
| | | | [originally from svn r7364]
* Dariusz Olszewski's changes to support compiling for PocketPC. ThisSimon Tatham2007-02-26
| | | | | | | | | | | | is mostly done with ifdefs in windows.c; so mkfiles.pl generates a new makefile (Makefile.wce) and Recipe enables it, but it's hardly any different from Makefile.vc apart from a few definitions at the top of the files. Currently the PocketPC build is not enabled in the build script, but with any luck I'll be able to do so reasonably soon. [originally from svn r7337]
* Add James Harvey's excellent new puzzle, `Galaxies'.Simon Tatham2007-02-22
| | | | [originally from svn r7304]
* Replicate r7285 from PuTTY: make keyboard input work in HTML Help.Jacob Nevins2007-02-13
| | | | | [originally from svn r7286] [r7285 == 3d78bf9b261b4bfd30ae00d5ba43744c4144c934 in putty repository]
* In Windows/Gtk front-ends, consistently use the ellipsis convention for namingJacob Nevins2007-01-04
| | | | | | menu items which bring up dialogs. [originally from svn r7058]
* Add NO_HTMLHELP and turn it on by default in Makefile.cyg.Jacob Nevins2006-12-28
| | | | [originally from svn r7033]
* Actually introduce the ability to build the Windows icons into theSimon Tatham2006-12-27
| | | | | | | | | | | | | | | | | | | Windows puzzle binaries. This checkin involves several distinct changes: - mkfiles.pl now has an extra feature: if an object file is listed in Recipe with a trailing question mark, it will be considered optional, and silently dropped from the makefile if its primary source file isn't present at the time mkfiles.pl runs. This means people who check out the puzzles from Subversion and just run mkfiles.pl shouldn't get build failures; they just won't get the icons. - all the .R files now use this feature to include an optional Windows resource file. - the .rc resource source files are built by icons/Makefile. - windows.c finds the icon if present and uses it in place of the standard Windows application icon. [originally from svn r7020]
* Minor const fix.Simon Tatham2006-12-24
| | | | [originally from svn r7013]
* HTML Help support for Puzzles, with the same kind of automaticSimon Tatham2006-12-24
| | | | | | fallback behaviour as PuTTY's support. [originally from svn r7009]
* Cleanup: relieve frontends of the duty to callSimon Tatham2005-10-22
| | | | | | | | | | | | | midend_rewrite_statusbar() and check the result against the last string returned. This is now done centrally in drawing.c, and the front end status bar function need only do what it says on the tin. While I'm modifying the prototype of drawing_init(), I've also renamed it drawing_new() for the same reason as random_new() (it _allocates_ a drawing object, rather than just initialising one passed in). [originally from svn r6420]
* Patch from James H which initialises a couple of Windows API objectSimon Tatham2005-09-10
| | | | | | handles to NULL before accidentally trying to use them for anything. [originally from svn r6282]
* Take the Windows taskbar into account when deciding on the maximumSimon Tatham2005-09-06
| | | | | | | | | | | size of the puzzle window. This has involved some _completely stupid_ window manipulation: in order to figure out in advance how big I want my main window to be, I first have to _create_ the status bar so I know how tall it is; but since I can't reparent it into my main window after I've created it, I then have to throw that status bar away and create a new one. *sigh* [originally from svn r6276]
* Memory leak and type safety fixes from James H.Simon Tatham2005-08-25
| | | | [originally from svn r6219]
* Over-enthusiastic assertion introduced in the printing revamp wasSimon Tatham2005-08-24
| | | | | | causing Mines to crash one second after starting a game. Oops. [originally from svn r6214]
* Memory leak in the new printing stuff, plus a couple of commentSimon Tatham2005-08-22
| | | | | | corrections. [originally from svn r6199]
* Native Windows printing support, using the infrastructure I put inSimon Tatham2005-08-20
| | | | | | | | | | | | | | | | | | | | | place in r6190. I'm quite pleased that I didn't have to modify the printing infrastructure _at all_ to make this work; the only source change required outside windows.c was the addition of a trivial utility function midend_get_params(), and that was for the benefit of bulk puzzle generation rather than anything to do with actual printing. As far as I can tell, all printable puzzles now print almost indistinguishably from the way they print under Unix. If you look closely the font is slightly different, and the Windows standard hatching doesn't seem to be quite as nice as the kind I did by hand in ps.c (and, particularly annoyingly, hatched areas don't show up at all for me when I print to a file and use gv, though they come out fine on the printer itself); but it's all there, and it all works. [originally from svn r6193] [r6190 == af59dcf6858264103bbc621761feee3aed5aaf2a]
* Substantial infrastructure upheaval. I've separated the drawing APISimon Tatham2005-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as seen by the back ends from the one implemented by the front end, and shoved a piece of middleware (drawing.c) in between to permit interchange of multiple kinds of the latter. I've also added a number of functions to the drawing API to permit printing as well as on-screen drawing, and retired print.py in favour of integrated printing done by means of that API. The immediate visible change is that print.py is dead, and each puzzle now does its own printing: where you would previously have typed `print.py solo 2x3', you now type `solo --print 2x3' and it should work in much the same way. Advantages of the new mechanism available right now: - Map is now printable, because the new print function can make use of the output from the existing game ID decoder rather than me having to replicate all those fiddly algorithms in Python. - the new print functions can cope with non-initial game states, which means each puzzle supporting --print also supports --with-solutions. - there's also a --scale option permitting users to adjust the size of the printed puzzles. Advantages which will be available at some point: - the new API should permit me to implement native printing mechanisms on Windows and OS X. [originally from svn r6190]
* Cleanups from James H: a few missing statics, a precautionary castSimon Tatham2005-08-03
| | | | | | | | | or two, a debugging fix, a couple of explicit initialisations of variables that were previously read uninitialised, and a fix for a whopping great big memory leak in Slant owing to me having completely forgotten to write free_game(). [originally from svn r6159]
* Quite a few instances of the Cardinal Error of Ctype were turned upSimon Tatham2005-07-17
| | | | | | by a grep I just did. Oops. [originally from svn r6113]
* draw_polygon() and draw_circle() have always had a portabilitySimon Tatham2005-07-03
| | | | | | | | | | | | | | | | | | | constraint: because some front ends interpret `draw filled shape' to mean `including its boundary' while others interpret it to mean `not including its boundary' (and X seems to vacillate between the two opinions as it moves around the shape!), you MUST NOT draw a filled shape only. You can fill in one colour and outline in another, you can fill or outline in the same colour, or you can just outline, but just filling is a no-no. This leads to a _lot_ of double calls to these functions, so I've changed the interface. draw_circle() and draw_polygon() now each take two colour arguments, a fill colour (which can be -1 for none) and an outline colour (which must be valid). This should simplify code in the game back ends, while also reducing the possibility for coding error. [originally from svn r6047]
generated by cgit v1.1 at 2026-05-20 01:01:40 +0000