Search the Community

SudokuHelper is an application that acts like an electronic Sudoku grid. It supports 9x9, 12x12, and 16x16 Sudokus, both in the classic and Gosu variant, where cells can be marked to only accept even numbers. The application neither creates Sudokus itself nor provides a solver for them; it is just a more convenient way to solve a Sudoku from a magazine or other external source than doing it on paper, using pencil and eraser. The application's main features are: Invalid cell values are marked in red. Candidate values can be added and removed from a cell. Setting a cell's value will automatically remove candidates no longer possible in other cells. All actions can be undone, the undo stack is only limited by available memory. Named marks can be set for the current undo stack state and one can later restore the stack to such a named mark. The complete Sudoku can be saved to file, including the undo stack, and later loaded again from such a file. The project can be found on GitHub: https://github.com/PeterBelow/SudokuHelper The code is a good example (IMO) of how to uncouple the UI from the "buisness" code using interfaces, in a kind of MVC design. It is free (public domain) without restrictions.

Dear fellow programmers, I'm trying to stick to Nick Hodges advice and keep the code loosely coupled, separating business from presentation, and observing oop principles. In order to accomplish this I: 1) code against interfaces; 2) adopted a sort of MVVM design pattern. Sort of because i don't really understand the difference among MVVM, MVC, MVP, etc. I thought that if I have business logic, view logic and persistence logic in separated units, apart from the views, and fully testable, I'd would be Ok to go; 3) I use Spring4D all around because in the future I want to take advantage of it's dependency injection capabilities. When it came to implement LiveBindings I stumbled into a problem: in order to create the adapters I need the actual classes, and to make the class implementation details visible in the module I call ViewModel would defeat all the isolation I accomplished so far. The solution I came up with is to keep interfaces in one module, implement them with abstract classes in another codeless module, and inherit from them and writing all the code in a third unit. I could keep the interface and it's abstract implementation in the same unit, both have no code, or separated and add another level of organization. That said, I kindly ask for your input on the solution I came up with. My goal is to keep Nick happy with interfaces, keep Delphi happy with classes, and myself happy with Spring4D. Is this the way to go or is there a better solution? Thank you so very much in advance . Best regards, Carlos Tré

Please forgive the question if it's seems obvious. I have always Implemented an interface in a new class the hard way in Delphi by copying the interface members from the interface into the class and using class completion to generate the methods. Is there a way to do so in the Delphi IDE without such a manual brute force technique? I don't see anything in the Refactor menu and invoking Class Completion on a class with an unimplemented interface does nothing. Is this only possible through a third party IDE add-in like MMX? I would think that in the age of interface based development, making it easy to define and implement interfaces would be a well supported use case within the IDE, so I am assuming I just don't know of it. It's a snap in Visual Studio.