forums.silverfrost.com

[DanRRight]

Well...that was not easy...it's like going to Microsoft Windows programmers dirty internal kitchen ))

I've tried to extend your example above but still failed, clearly i do not understand something. Is there any example of using %mg? Without code sample the %mg description in the help file looks unfortunately like highly encrypted message. Reading its description below i felt completely lost at the WM_NOTIFY and already at the next sentence got very bad feeling reading about set_mg_return_value@

Ideally would be to see simplest working code snippet of using keyboard with %gr[full_mouse_input] which, say, is reacting on key for letter A or number 5 or left arrow from Windows messages

-------------------------
winio@(‘%mg’, msg_no, cb_func)
integer msg_no (input)
external cb_func

This format provides direct access to specified Windows messages. It should be used with care since it is possible to interfere with other ClearWin+ processing.

msg_no is the message number of the message to be processed. User numbers should begin at WM_USER +1000. cb_func is the call-back function that is to be called when the message is received. The call-back function can use clearwin_info@ with the strings 'MESSAGE_HWND', 'MESSAGE_WPARAM', and 'MESSAGE_LPARAM' in order to get the standard arguments for a Windows call-back function.

When writing the %mg call-back function, use a return value of 3 if you want ClearWin+ to apply the default processing of the message msg_no. Other values have the usual effect (zero closes the window etc.) but cause the default processing to be bypassed. Occasionally the internal Windows dialog procedure that processes messages requires a particular return other than the default value which is zero (e.g. under certain conditions when using WM_NOTIFY). In this case you should make a call to the subroutine set_mg_return_value@ before returning. This subroutine takes one integer argument which is the value to be returned by the internal Windows dialog procedure.

[PaulLaidler]

OK I will aim to put together some sample code when I get a minute.

[PaulLaidler]

Here is a program that uses a %gr area and allows you to type into the status bar.

[DanRRight]

Holly shmolly...thanks for the example, i'd crash before finding this solution. But we have to admit, the solution is kind of antiintuitive. I still do not understand how this line works

i=winio@('%mg&', WM_KEYDOWN, mg_func)

And since all the warnings about %mg is also such specific callback content important? This is because as to the keys generated, the get_wkey@ or get_wkey1@ look more familiar for Salford/Silverfrost compiler users then wparam which not everywhere coincides with key and seems misses arrow keys. All in all is the code below without clearwin_info@ etc calls legitimate? Seems it works fine...

[PaulLaidler]

I am not sure that your code will always work but it is an interesting approach.

The difference is that get_wkey@ takes the value from a buffer whilst WM_KEYDOWN responds the the current key stroke. Maybe if you included a way to clear the buffer then the two would be equivalent and yours would be the simpler approach.

[DanRRight]

As i wrote before i still do not understand how this code works. What specifically do you mean with cleaning the buffer, why it is needed and how it can be done?

Does %mg following any changes in WM_KEYDOWN (and this variable seems tracks any keyboard presses in Windows) and if it sees change in WM_KEYDOWN it calls call-back function? is this how it works?

I was testing this approach for a while and initially all was ok as well as it is seems ok with the small example i wrote above. But installing it into large code i found recently it stopped to work properly. I have to push button several times to get action. Could be other bug, the code is almost out of damn 32-bit OS stack limit 1.6GB ...

[PaulLaidler]

Basically you need to get some idea of how the Windows messaging works particularly via the Windows API SendMessage. %mg provides a way for ClearWin+ to pick up a message (in this case a key down message) and pass it on to you the user. So if you look up SendMessage and find out what is delivered with the ID WM_KEYDOWN then you will see how the parameters wparam and lparam are used for this message.

The traditional way of handling keyboard input was to put the actions into a buffer so that programs could pick up the information via a sutable read buffer function. A number of key strokes can thus be stored before a program starts to get them. get_wkey@ either emulates this kind of buffer or uses an existing one provided by the system (the former I think).

What I was trying to say was that there is a possiblitily for a particular WM_KEYDOWN to get out of sync with the first key in the keyboard buffer, in which case the wparam info will not match the result of the call to get_wkey@.

[DanRRight]

I will put this into followup and investigate how both methods differ later after resolving more serious issue -- why my code above stopped working when placed in the larger code which is balancing near the limit of another "buffer" - stack size approaching now 1.4GB almost nothing leaving for the code (here even debugger sometimes hiccups showing A = 0 in the equation A = B + C with B>0 and C>0 requiring Windows reboot)

Yes, handling keyboard could sometimes be tricky. In regards of your initial code example on the first page of this thread with full_mouse_input: is there any way in Clearwin to handle mouse scroll wheel ?

[JohnHorspool]

Dan,

[DanRRight]

Thanks...I've made this small addition to the code above to demonstrate it, please check if this is how wheel supposed to work?

[JohnHorspool]

Dan, yes, rightly or wrongly that's how I use it. I don't find the actual value reported is much use, so I just check for a negative or positive value and act on that.

[DanRRight]

OK. And it shows larger values then +1 and -1 when you move it fast, like 6-7, right? I am trying to understand if this hidden trickery is PC specific, mouse driver specific or OS specific...

[JohnHorspool]

Dan, you must have quicker fingers than me, if I try really hard I might get a 4 !

I don't think this is important though, for every ratchet on the scroll wheel I get a returned value, so simply the more you rotate the wheel the more returns you see, I think that this is sufficient for a continuous zoom in/out effect on a graphics screen for instance.

[DanRRight]

Just make your mouse and keyboard a bit faster then in default settings, John

[aebolzan]

Well, well, I have eventually found how to manage Simpleplot plots within a %dw graphic window, and how to get the value of the points inside it. As it seems to work very well, I would like to share my findings in this respect, as it could be usefull for someone else. Here is the code for a simple plot (remember that one has to link it with the simpleplot.dll library). My previous solution was based on a pure use of Simpleplot and Simpleplot windows, which is not very nice if one is deeply involved with a Clearwin approach. The powerful facilities of the old Simpleplot are extremely useful for making almost any graphics (thanks David Butland & Co.!).

Agustin

MODULE SPWIN ! Contains definition of values to pass to DDDATA
INTEGER,PARAMETER :: SIMPLE_WINDOWS_WINDOW=1,SIMPLE_WINDOWS_PRINTER=2, &
&SIMPLE_WINDOWS_DIB=4,SIMPLE_WINDOWS_METAFILE=8,SIMPLE_PERCENT=0,SIMPLE_PIXELS=1,SIMPLE_MM=2
TYPE SIMPLE_WINDOWS_DATA_STRUCT_T
INTEGER :: iOpc ! Corresponds to C++ long int
INTEGER :: iPtr ! Address of OpCode specific data
END TYPE SIMPLE_WINDOWS_DATA_STRUCT_T
TYPE SIMPLE_WINDOWS_HDC_DATA_T
INTEGER :: hDC ! device context handle
INTEGER :: iWidth, iHeight ! plotting area
END TYPE SIMPLE_WINDOWS_HDC_DATA_T
TYPE SIMPLE_WINDOWS_SIZE_T
INTEGER :: iUnits ! SIMPLE_PERCENT, ..._PIXELS, ..._MM
INTEGER :: iWidth, iHeight, iDepth
END TYPE SIMPLE_WINDOWS_SIZE_T
TYPE SIMPLE_WINDOWS_ORIGIN_T
INTEGER :: iUnits ! SIMPLE_PERCENT, ..._PIXELS, ..._MM
INTEGER :: iX, iY
END TYPE SIMPLE_WINDOWS_ORIGIN_T
TYPE HDC_DIM_TYPE
INTEGER*4 iBitmapDC, iWidth, iHeight
END TYPE HDC_DIM_TYPE
TYPE (HDC_DIM_TYPE) :: HDC_DIM
INTEGER, PARAMETER :: SIMPLE_WINDOWS_END_LIST = 0
INTEGER, PARAMETER :: SIMPLE_WINDOWS_SET_WINDOWNAME = 6
INTEGER, PARAMETER :: SIMPLE_WINDOWS_SET_HDC_DIM = 7

! Useful definition of data structure to hold BitmapDC to pass to SIMPLEPLOT

Contains

SUBROUTINE SP_SupplyBitmap ! Pass Bitmap to SIMPLEPLOT
! Set up a Static (SAVEd) array of OpCodes. Each OpCode consists of an
! OpCode ID followed by an optional address of a data structure.
! The parameter block address is passed to SIMPLEPLOT by SUBROUTINE DDDATA.
!
! In this example:
! SIMPLE_WINDOWS_SET_HDC_DIM specifies that the next integer is the address
! of a data structure consisting of a Bitmap DC followed by its dimensions
! SIMPLE_WINDOWS_END_LIST is the mandatory end of list item which does not
! require the address of a structure
TYPE(SIMPLE_WINDOWS_DATA_STRUCT_T), DIMENSION(2) :: OpCodes
SAVE OpCodes
OpCodes(1)%iOpc = SIMPLE_WINDOWS_SET_HDC_DIM ! hDC + dimensions
OpCodes(1)%iPtr = LOC(HDC_DIM) ! See definition of SPWIN above
OpCodes(2)%iOpc = SIMPLE_WINDOWS_END_LIST! End of list
CALL DDDATA(LOC(OpCodes))! Notify SIMPLEPLOT
CALL DEVNAM('WINDOW') ! Select Window
CALL OWNNEW(.TRUE.) ! Inhibit 'Continue' button
END subroutine SP_SupplyBitmap
SUBROUTINE UpdateWin
CALL OUTBUF ! Flush buffers
CALL WINDOW_UPDATE@(HDC_DIM%iBitmapDC) ! Copy Bitmap to window
END subroutine UpdateWin
END MODULE SPWIN