PDA

View Full Version : Lorenz 3D - & question



RobbeK
11-04-2014, 00:52
Hi all,

Another system of 3 non-lin dif equations ...
You can use the arrow Pg U/D keys to navigate. - u can change the a , b & c parameter as well ...
S saves an ASC file -- result via MeshLab (could be nice for a 3D print).

Question : how do one stop the interaction between the arrow keys and the left textbox.


t.i.a.

Rob

ReneMiner
11-04-2014, 07:47
...
Question : how do one stop the interaction between the arrow keys and the left textbox.

t.i.a.

Rob


Edit:
The behaviour is sadly built-in to windows, seems the ms-developers standpoint is: Windows is the OS and the OS makes the rules how keys work so they occupied these keys (Tab, Arrows, Alt, F10 etc.) and all windows-users have to live with that decision now. However you may visit their compliant departement :D

Don't know if helps - I append some complete list of UI-equates here, sorted by alphabet - can not be wrong to have it in stock and is much easier to read than ms-documentation, especially when searching for a certain message where you only have a small clue as "Focus" etc. (CTRL+F & F3 are your friends)

The %WM_...Focus-messages seem only to apply to the window itself but in general any control is a window too - but I'd try the simple %BN_-messages as first - even if it's a canvas

I guess there's some callback-event-msg for "Control Lost Focus" (KillFocus?) and you could recheck in this moment if still arrow-keys held (GetAsyncKeyState) and set focus back to picturebox, image, canvas etc.

As I read on some MS-doc it's not recommended to set focus (f.e. back to the old control) within the Got-focus-event so one might do it already if the old control loses focus and before it's set to the new control.

RobbeK
11-04-2014, 11:12
Ah, thanks very much sharing this -- I can use it ;-)

Well, I first tried to change the object in focus inside the main timer loop (in RendermyImage ...) , but this only works if the refresh rate of this event is long enough to read another event. (= slow broken animations). If the refresh rate is very fast, the buttons , textboxes etc... can not be reached ....

But a "set focus" call after each key is read seems to do the trick ...

thanks again,

Rob

peter
11-04-2014, 11:55
Cool Robby 3D Lorenz. :o

mike lobanovsky
11-04-2014, 15:32
Hello Rob,

This one is really cool, thanks a lot! :)

thinBasic uses "dialog" windows for its UI and indeed, this window class has inter-control focus-handling logic prebuilt in it, as ReneMiner notes correctly above. This is very convenient for document-handling interfaces but may become a nuisance for other tasks even if you use the SetFocus() API.

An alternative way will be to create your own "frame" windows from scratch using CreateWindowEx() with your own custom window message handling. Frame windows are more generic than dialogs and they don't switch keyboard focus between controls automatically. You will be however responsible for creating your own keyboard focus scheme from ground up in any way you like. It may seem too complicated to do in every little demo but you can design an include file once and for all and simply add it to your new projects making minor adjustments to it only as needed for a particular application. Designing such an include file will however be a separate project unto itself and would require considerable effort and a lot of debugging and polishing.

You can also change the behavior of keyboard focus for a particular standard control by subclassing its window and handling its window messages in your own custom event-handling function. This is however hardcore Windows programming that should be done only for some specific task in a given project.

I don't think that such small snippets as we publish on the forum are really worthy of hardcore programming efforts. This means we should simply bear with these minor inconveniences as there is no easy way to remedy them immediately.

Regards,

RobbeK
11-04-2014, 22:02
Thanks Peter,

Hi Mike,
Ah, ok .. I'm rather softcore these days... What's your opinion . did MS could have made it more complete ??
With textboxes is not that of a disaster, but if sliders or in focus that's something else (they also react on the arrow-keys) - I also wonder why it specifically takes a certain object to correspondent with these keys ?
Enfin, never mind - a SetFocus just after the key hit seems a cure. I also notice a difference between in and outside a timer loop .. !?

Thanks for answering , Rob

mike lobanovsky
11-04-2014, 22:55
My advice is take a day off of mathematics, read up on RegisterClassEx() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633587%28v=vs.85%29.aspx)/CreateWindowEx() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms632680%28v=vs.85%29.aspx)/WNDCLASSEX (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633577%28v=vs.85%29.aspx) - they contain all the info needed to create user-defined frame windows. These windows don't have a hardcoded keyboard focus behavior and will allow you to use the arrow and letter keys for navigation and other purposes regardless of sliders and similar common controls.

All this may, and can, be implemented in thinBasic and/or OxygenBasic scripts. Once done, you won't be restricted to the language's prebuilt functionality any more. :)

[EDIT] I can't code in thinBasic fast enough but here's a quick and dirty sample written in FBSL. It can be reproduced easily in any BASIC that has access to WinAPI and variable/function pointers, including thinBasic and Oxygen. It generates a raw frame window whose handle (hMyWnd in this case) can be used to accomodate raw or language-specific controls. The controls will not however be governed by thinBasic's predefined dialog-based keyboard focus so your arrow and character keys may be used for navigation. Yet the focus may still be directed to a particular control by clicking it with the mouse or surfing the window with Tab presses till the focus reaches the control in question.

RobbeK
12-04-2014, 10:50
Thanks Mike,
Already read the first links this night - downloaded your example now and I will study it.
It seems it's even possible to create an extended window out of a non extended class registration (but I'll have to read this all again to absorb it).
Somewhat complicated but IMHO the SetFocus switches also should work and doing the trick with a small amount of extra code. The only slight problem is of course when an object is used by the mouse it automatically gets the focus , this has to switched back to something where key activity is "void" .
Attached something clearer than my explanation (Albert Einstein once said, if someone gives you a difficult explanation , he doesn't understand what he is talking about ;-) --

best Rob.
FBSL is still in the garage -- (I'm afraid of C , postponing learning it for many decades ))))
(we had Pascal @ school / Lisp @ the job )

mike lobanovsky
12-04-2014, 14:41
Rob,

Using raw SetFocus() is not the best, and certainly not the most elegant, idea. It should be used in a subclassing scenario to completely preclude focus shifting to an unwanted target.

So here's a more elaborate example to finish off this topic. It uses two buttons on a frame window. On app start, the focus can be toggled between the both buttons with Tab and arrow keys. You can see it by watching the focus rectangle switching from one button to the other (snapshot 1 below).

Now when the focus is on the upper button, click it with the mouse or press Space to trigger its click. The click will subclass the lower button to reject keyboard focus completely. Now you will not be able to move the focus rectangle to it with either Tab or arrow keys and pressing Enter or Space will always trigger the upper button only (snapshot 2 below). However, you'll still be able to fire the lower button with a mouse click but not with a keyboard key press.

The code uses one more function similar to the frame window function which replaces the lower button's original message handler routine with a user-defined function. Such replacement is called "subclassing". All the messages that the new handler doesn't process are transmitted to the button's original message handler. The original message handler should always be, and actually is, restored before the application quits. The code is commented and additional info and particularities can be googled in the MSDN.

These techniques are natural to Windows programming in any language that permits them, and they can easily be reproduced in thinBasic and OxygenBasic too. This has nothing to do with FBSL's DynC and once you understand the logic of the process, you will be no more restricted to peculiarities of dialog windows which thinBasic is built around.

Hope this helps, :)

peter
12-04-2014, 15:49
here's another button test.

mike lobanovsky
12-04-2014, 20:09
@Peter

Thanks for your help!

@Rob

Peter's sample shows that in OxygenBasic, the user builds their main window from scratch for every project so it will be easy to create a non-focusing frame window in this language; in fact it's even easier than to spawn a dialog window. Oxygen's main loop is usually of a simple form

While GetMessage Msg,0,0,0
TranslateMessage Msg
DispatchMessage Msg
WEnd
Such a loop will not allow keyboard focus to follow Tab and arrow key presses at all and subclassing won't be necessary as a consequence.

OTOH thinBasic (and FBSL, for that matter) evidently makes use of IsDialogMessage() in this loop (which is buried in the intrinsics of the language's core engine) to allow for arrow key focus navigation and also for Tab navigation among the controls that have a WS_TABSTOP window style:

While GetMessage Msg,0,0,0 ' many different implementations are actually possible
If Not IsDialogMessage(Msg, hDialogLikeWnd) Then ' process this window's messages as in a dialog window
TranslateMessage Msg ' process other windows' messages as in a frame window
DispatchMessage Msg
End If
WEnd

IsDialogMessage() works not only for dialog windows but also for frame windows of current thread even if they are created via API's from scratch outside the framework of the language. In this case, subclassing as shown in my example will be a must to effectively bounce the keyboard focus off the controls that can otherwise grab Tab and arrow key input in such languages as thinBasic and FBSL.

RobbeK
13-04-2014, 10:51
Thank you Mike, Peter .. this is all very educational ;

(as an experiment , maybe I can try to make TB interface with a Java server application (I already have a jar file that on its turn interfaces with the Java Swing libraries ) it has some interesting possibilities like tagging graphics etc... I already use it for Lisp applications and last week I was able to extend and run some opengl, glu , glut , freeglut stuff (and producing a heap of crashes using the SDL library ) )

thanks again, Rob