Leaderboard

I was hoping to show a screenshot snippet of my XE7 version of Day-1's puzzle as proof. I mean, I think some of you may like it. As soon as I figure out something with the image, I will post it here. I haven't looked at any of the videos posted here because I don't want to know what the puzzles are until I tackle them as I can if I can. Also, I just read Day-2's puzzle. It is interesting. I have some ideas racing through my head already, and once you see my first puzzle you may be able to figure it out, but I work the night shift and I need to get some sleep.

What is your problem?

You should post your final syntax to help others who encounter that same issue.

Sorry, but you are not on the right track, not even close. You can't pass a message ID to SetWindowsHookEx() like you are doing. The 1st parameter expects a hook type (one of the WH_... constants), not a message ID. To hook window messages, you need to specify either the WH_GETMESSAGE or WH_CALLWNDPROC/RET hook type, and then look for your desired message ID inside of your hook callback function. However, in this particular situation, CM_VISIBLECHANGED is a private message to the VCL only, it does not go through the Win32 messaging system at all, so a SetWindowsHookEx() hook will never see it. The only way you can intercept CM_VISIBLECHANGED is to either: subclass the WindowProc property of every TControl you are interested in. derive your own UI classes that either override the virtual WndProc() or DefaultHandler() method, or define a 'message' handler for CM_VISIBECHANGED. use a detouring library, such as MSDetours, to hook into the non-virtual TControl.Perform() method directly (which is what the TControl.Visible property setter calls to send out CM_VISIBLECHANGED). This won't help you in this particular situation, but in general to retrieve the relevant HWND in a SetWindowsHookEx() hook: for WH_GETMESSAGE, the lParam is a pointer to a MSG structure, which has an HWND member. for WH_CALLWNDPROC, the lParam is a pointer to a CWPSTRUCT structure, which has an HWND member. for WH_CALLWNDPROCRET, the lParam is a pointer to a CWPRETSTRUCT structure, which has an HWND member.

@JohnLM Great. This is perfectly reasonable .. for at least two reasons. 1) The challenge is about achieving a solution - dissecting the problem in a way that makes it solvable. 2) Eg in the day 2 and 3 problems, I put the data in Excel to manipulate it around, get a perspective on the contents, and to provide results to crosscheck against while I am only part way towards constructing my approach. I have kept them in my Github repo. 3) Also, some of the challenge is just reading in the data ... which can be sometimes tedious and/or obvious. I have used Excel and Notepad++ to make the data into a Delphi unit holding the info, when moving text with code was unrewarding. PS : There's a cool video from the guy that creates and runs the challenges from very recently. People solve the problems in many different ways - and not just with code. CppNorth - Keynote: Advent of Code, Behind the Scenes - Eric Wastl

Not sure who Dave is.... Delphi doesn't know that the type of the thing to the right of the equality operator is an array, it thinks it is a set. That's why you get the error. You might not like this, but this is just how it is right now. From the language perspective, there is clearly some magic disambiguation applied in the case of the assignment operator that isn't applied elsewhere. As Remy says, all you can do is to open a ticket. Shooting the messenger isn't going to get you anywhere. But even if the code did compile, what would you want it to do? For dynamic arrays, like other reference types, the equality operator = means reference equality. But I suspect that you would want value equality. So even if this code ever compiled, I don't think it would do what you want to do. In which case you will need to implement a method or function to perform value equality testing, and so the topic becomes somewhat moot.