%WM_KeyDown a CBMSG ?

[RobbeK]

Hi all,

Is it possible to intercept keyboard events within the mainwin_proc callback function ??

I'm finishing something, but have to add zoom and navigation, I want to do this with the keyboard ...

thanks in advance (been browsing the documentation, but probably looking at the wrong place)

Rob (code does 250 iterations (for this image) with ease)

[RobbeK]

oops, problems solved by using a timer ...

Zoom, navigate with cursor keys and PgUp PgDN now ,


Rob

still want to know about %wm_keydown ;-)

[Petr Schreiber]

Hi Rob,

I know Mike disagreed a bit with me on the timer, but it is essential for Windows application to keep responsive, and in this case it is something affecting the app design, so better to start it.
I agree optimizations should go last, but this is not optimization, but major design decision.

Few notes:

SELECT CASE is better to distinct between control ids in WM_COMMAND
Just CBCTL is not enough, in case of button you need to test for specific message, BN_CLICKED, to avoid "false clicks" caused by other button events (setting focus, ...)
Better to render animation frame using timer - the button kicks in only the start, rest is done in timer
I introduced separate %timer_Input and %timer_Animation to handle both periodical tasks

I think the animation control via keys is more responsive now


WM_KEYDOWN does not allow multikey combinations, and I think it gets blocked by things like focus on textbox, I don't recommend it for this application


I did all these mods to the code, feel free to ignore :), but I think it is an improvement for further code maintenance.


Petr

[RobbeK]

Hi Petr,

"feel free to ignore" -- of course not , every help is very welcome and I'm learning a lot from your modifications !
I think Mike's remark was only about that piece of "throw-away" code, certainly nothing in general and correct about my intentions.

"Just CBCTL is not enough" .. still used to the more prefabricated p.e. sub button1_onDblClick etc ... I guess (i understand the difference).

Infact hiding those buttons is not the best either I think - they are still receiving events , but enable disable only work within timer events ??

thanks again, Rob

[mike lobanovsky]

I think Mike's remark was only about that piece of "throw-away" code, certainly nothing in general and correct about my intentions.

@Petr

Yes, Rob is perfectly correct. I didn't mean to contradict you, I was hinting (in fact, teasing and intriguing) that Rob was (and actually still is) just emitting pieces of "throw-away" code on his road to a solution to a more sophisticated problem I'd asked him to help me out with. Rob is much stronger at math than my poor self and I was lucky to have him agree to look into the problem. http://www.fbsl.net/phpbb2/images/smilies/icon_smile.gif

Certainly, GetAsyncKeyState() is a much, much better solution than mere WM_KEYDOWN. It allows the interception of several keys pressed simultaneously while the message only deals with the most recent key press at a time. With GetAsyncKeyState() one can e.g. fly up-right diagonally while progressing simultaneously (zooming on the Z axis) into the scene in both 2D and 3D.

@Rob

The new navigation capability is fantastic! http://www.fbsl.net/phpbb2/images/smilies/icon_smile.gif

I would only suggest one thing, if you don't mind, since we've already started talking about design decision making. Please don't assign navigation keys at random and prefer to avoid arrow keys because they don't let you use your right-handed mouse conveniently.

There is a convention to make navigation easier and more expectable for millions of people over the world (assuming a standard QUERTY layout is used; french-style AZERTY keyboards use different keycodes however the keys are located at the same positions):

1. "W" zooms into the picture on the Z axis while "S" zooms out. The keys may be duplicated with "Up" and "Down" arrows for left-handers who have their mouse on the left side of their keyboard.

2. "A" strafes (glides, pans) left while "D" strafes right. The keys may be duplicated with "Left" and "Right" arrows, respectively.

3. "Q" pans the picture up while "Z" pans it down. The keys may be duplicated with "PgUp" and "PgDn", respectively. There are some more conventions among gamers but they are more game-specific and omitted here for brevity.

Such a control system also allows you to simultaneously use your mouse in your right hand to aim at your destination while actually flying around with your left hand using the keys I described above. Fraxter3D and all my other 3D programs are built around such a system. You'll get used to it too after some 10 minutes practicing.

I'm not kidding. Unexpected and cumbersome navigation may seriously spoil the reputation of a particular program:

http://www.fbsl.net/phpbb2/download/file.php?id=1463

Regards, http://www.fbsl.net/phpbb2/images/smilies/icon_ml_noel.gif

[RobbeK]

Thanks for these important tips, Mike .. (Speaking DOS : "Keyb be" here ! .. semi French ).

Once again - this code is not optimized - scrolling the bitmap 2 lines and calculating the whole BMP all over, is of course nonsense - with the correct code it may upto 100x? faster (move the memory block 2x50 byte and calculate the new 100 z values, will be a lot faster than 250 000 new ones)-- even there may be clever zooming .. the purpose for the moment again only is prototyping the inside fractal representations.

till later,

Rob

[mike lobanovsky]

... scrolling the bitmap 2 lines and calculating the whole BMP all over, is of course nonsense - with the correct code it may upto 100x? faster (move the memory block 2x50 byte and calculate the new 100 z values, will be a lot faster than 250 000 new ones) ...

Exactly! And not only that; there are other very clever techniques of fooling human eye into thinking that deep fractal zoom is very easy and fluent in real time!

Now imagine I'm using my mouse cursor to pan the program viewport and point to a particular spot within a Julia "tentacle" while I'm zooming into it with my left hand fingers. As that spot rolls into the center of my view, the clever program's main thread will plot only the centeral rectangle approx. 1x1 inch large at full resolution and the remaining periphery in the viewport, at much lower resolution. There are also several helper threads spawned concurrently to overwrite those low-res peripheral quadrants with high-res picture which naturally takes more time. But the central rectangle already is high-res! In the meantime, all my attention is focused on this rectangle only and I'm not noticing that the periphery is turning high-res too but at a much slower pace. The effect is very similar to how modern JPEG's are downloaded to your browser via a slow net connection except that the central portion of your fractal viewport is always high-res and you simply don't notice that the viewport's periphery is not! The illusion of free flight at a terrific speed is perfect! http://www.fbsl.net/phpbb2/images/smilies/icon_biggrin.gif

Of course this is high-class aerobatics but it shows that there are no limits to perfection.

http://www.fbsl.net/phpbb2/images/smilies/icon_ml_noel.gif