There is an interesting action that occurs.
As designed when you move the cursor to an icon, a tooltip opens, then when it leaves the pixel of the icon the tooltip turns off. (if any mouse move message is a pixel not on that icon, tooltip closes)
Unless you are on the home island of Japan, then the tooltip does not turn off till the cursor leaves a hex on the home island or goes over a ground or naval unit tooltip, or an anchor, airfield, or flag icon in another hex.
This is a different effect then the rest of the map, it only occurs on the home island. I suspect there is some code added to the tooltip pop and close mechanism that does not allow the tooltip to close on the home island unless another tool tip is hovered over, or cursor leaves a homeisland hex.
Most likely there was some bug with the amount of icons on the home island popping and unpopping tooltips, and the speed of computers in the original code from early 2000s so that was a hack to stop some issue of qued tooltips runninig behind the cursor.
However if you move the cursor from Navy yard to flag icon or airbase icon, their is no opening of the tooltip for that item, until you move cursor off a home island hex or onto a unit or ships icon. That is a loss of functionality.
To reproduce the bug, or as designed workaround for slower computers and some tooltip issue, move the cursor over a flag icon on a hex of the home island of Japan, then move the cursor around the map while staying on the home island. Instead of the tooltip closing when it moves to a non icon pixel, it stays open. If you then move to an anchor or airbase in the same hex as the flag, it does not change to that icon's tooltip. The behavior only happens on the home island where there are many icons.
I suspect in the tooltip close code the area of code to look at is
if cursor xy is some pixel that is not an icon close toolbar window
then there is some code that says, 'unless pixel is in hex' then some list of home island hexes.
It is not a bounding box, it is actual hexes that have the different functionality, so it could be that the code is in a function where the code checks the hex on a mousemove message, then checks the data in the icon hovered over in the hex, or closes if not over an icon.
The issue is if you are looking at the navy tooltip, and want to look at the airbase tooltip, you have to move your mouse off the home island, or to a ship or ground unit first then back to the airbase you want to inspect with by seeing the tooltip.
Note, this functionality must have been added in intentionally. Debugging mouse messages are a pain since they post so often. (A tip to help debug mouse moves, create a function that posts messages to the window as a user message that then calls the same mouse move sub functions, and turn off mouse messages calling those functions, then script test the code in that section of code, so you can emulate functionality in debugger without having to mouse over GUI. Although not needed to fix this issue)
I suspect it is to try to stop some bug from appearing on slower systems that were popping many tooltips while moving over home island, so if that code fix is removed to make the behavior more consistent, and to have tooltips close when cursor moves to land or other icon on homeisland, check the functionality on a slower computer. Or emumutate a slower computer by turning off hardware rendering support or video memory usage or something like that, to make sure it was not added to correct some other issue.
Although if it was added to fix some other issue (stacked qued tooltips lagging and popping behind the cursor, for example), peeking the message fifo stack for mouse moves and only processing the last one, and removing others stacked in que would have been a better way to handle the issue if it was added in as a fix for there being many icons on home island, and slower response time of tooltip open close. Peek message has a remove ability(popping), set that and peek till getting last mouse move message, and skip actions on all others on the message stack, or there are many other ways to do same process. (note if some API layer is used to get to windows API, could be different).
Simple way to understand, pop mouse move message at front of function for all tooltip processing, if another in que, keep popping till you get to last one, then process on that message xy.
Also instead of create tooltip window, if 'create window' was to slow, window could be set to visible or not visible, or something like that, on each mouse move if speed of window was an issue. There are a few ways to fix that issue if the problem was speed of processing when tooltips were popped in high density icon area of home islands.
I suspect it was easier to not have to open and close the window, by simply not closing it on the home island, in the previous attempt to try to fix the issue
"On create tooltip", "if no window", "create window" <- creating slowdowns when many request for tooltips were qued. That is the guess of why they implemented 'no close on tooltip' on home islands.
where "On create tooltip window, get handle if already open", it gets the stored window handle to already open window and works faster.
So replacing the close tooltip functionality on the home island, to not closing tooltip window was added in for hexes of Japan home island.
Although switching it to a non visible window, and adding 'is window visible' to front of text processing, and always leaving Window open would correct the same problem, or not processing latent entries in message que(better idea).
The current fix being used creates a minor drop in functionality, and setting window visible not visible, or peeking messages, does the same thing but much faster if that was the issue.
It is a minor GUI issue, work around, move cursor off of island to close tooltip as a user workaround to close the tooltip, however it could be repaired pretty easily.
Although not relevant, my vid card is Nividea 765m 2 gigs,
program version the 126.96.36.1998r9 patched version
< Message edited by DHRedge -- 7/30/2013 7:50:55 PM >