forums.silverfrost.com

PaulLaidler · Posted: Wed Mar 04, 2015 8:21 pm Post subject:

I do not recall an existing ClearWin+ function that does this but it could be provided. Basically you need a call to SendMessage(hwnd, EM_GETSEL, ...) where hwnd is the handle of the control (from %lc) and the WPARAM and LPARAM arguments in the Microsoft documentation are used to get the positions of the first and last characters of the selection.

This may be enough to get you started. If not then post a reply here.

PaulLaidler · Posted: Wed Mar 04, 2015 9:23 pm Post subject:

Here is some sample code...

PaulLaidler · Posted: Thu Mar 05, 2015 5:54 pm Post subject:

a) The sample is just for illustration. Presumably you won't have a "Get selection" button. Can you indicate (preferably with sample code) how you plan to use the selection? I guess that you will need a way to monitor the selection as it changes.

b) SendMessage is a Microsoft API function. Search on Google with "MSDN SendMessage" etc.

PaulLaidler · Posted: Fri Mar 06, 2015 2:53 pm Post subject:

The trick is to reset the focus...

LitusSaxonicum · Posted: Sat Mar 07, 2015 6:27 pm Post subject:

Q: 'Where can I get a list of those commands'
A: MSDN
Clearwin+ documentation is a mixed bag. There are:
(a) Clearwin functions that are brilliantly described, but you need to look in the FTN95.CHM or some of the equivalent documentation.
(b) Clearwin functions that are badly described, where as well as FTN95.CHM, you might find something in CLRWIN.ENH (in the documentation folder) - occasionally the forum helps, and sometimes they are simply undocumented.
(c) Not available in Clearwin, but available by calling the Windows function.

Option (c) is what most of Clearwin does anyway, but parts of Clearwin don't simply act as a 'wrapper' for the Windows functions, those parts contain a lot of additional functionality, and the documentation rarely gives you a hint which they are.

My approach to something that I find difficult to program is to see how various other respect apps do it. If the authors of CorelDRAW, for instance, find it difficult to do something, then I know (1) it isn't easy, (2) it probably isn't standard in Clearwin, or even (3) perhaps it doesn't conform to the Windows user experience guidelines.

Eddie

LitusSaxonicum · Posted: Mon Mar 09, 2015 1:44 pm Post subject:

That's what the handle is for, and CALL SELECT_GRAPHICS_OBJECT@ is all about. The graphics commands might be 'in' the callback as you put it, they relate to whichever graphics object you last selected.

The handle for a graphics object is one that you choose yourself, not one that Windows chooses, so somewhere you have to set up different handles for your different objects. It is not the same as the handle you get back from a %hw or %lc which the Windows handle for the control or window. (You don't need to set the graphics area handle if there's only one graphics area, because whatever lurks in that variable is a valid integer and so will work).

If you set up a printpage, you use the same approach by switching your graphics to its handle, but then you need to revert to the screen afterwards.

Eddie

LitusSaxonicum · Posted: Tue Mar 10, 2015 7:02 pm Post subject:

John,

I don't understand all this module stuff, but the handle has to be accessible and not changed, and a geriatric like myself would put it in COMMON and know it was't going to get lost.
In debugging you perhaps have to write it out, and/or write out the return code from SET_GRAPHICS_OBJECT@

Taking a quick look at your code, the %gr handle CANNOT be obtained from%lw which returns the windows-returned handle for the window the graphics object appears in, not the user-supplied handle for the graphics area. Both %gr areas need their own handle if you wish to swap between them. I'll try to write an example.

Eddie

LitusSaxonicum · Posted: Tue Mar 10, 2015 8:04 pm Post subject:

LitusSaxonicum · Posted: Sat Mar 14, 2015 12:11 am Post subject:

John,

I can't follow the scoping rules of modules, so this is inhibiting my ability to help, but: if you have a %gr without a handle ten you can access it after it is created, but if you move to a different %gr you can never go back to the one without a handle.

PERFORM_GRAPHICS_UPDATE@() shouldn't have a parameter - it should work on the current %gr. I made a mistake, but as it seemed to work I left it in. Maybe it's an undocumented feature.

You need the apostrophe qualifier to %gr when you supply a handle to it and ^ when you have a callback.

In my example, you could easily write to both graphics areas in the callbacks, but I was conscious of space.

Eddie

LitusSaxonicum · Posted: Sat Mar 14, 2015 11:44 am Post subject:

As I readily confess, I'm a dinosaur in the Fortran world (and not a big or aggressive one) and the only reliable ways I know to pass any variables between routines are via common or through subroutine arguments - so my limitation.

When I put the grave modifier and the %gr handle in to this line in your demo:

PaulLaidler · Posted: Sat Mar 14, 2015 6:11 pm Post subject:

It is difficult for me to sort this out as I am out of office without a laptop.
I can see a gr without a percent before it and I can see more than one mis-applied %gr handle.

A %gr handle should appear as a fixed value that you supply in the program. It could be a literal constant (e.g. 42) or an integer parameter (e.g. integer,parameter::han=42). You choose the value (instead of 42).

I hope this helps. I am not that good at sending messages from a tablet.

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

grave accent " ` " not apostrophe " ' "

LitusSaxonicum · Posted: Tue Mar 17, 2015 2:01 pm Post subject:

The issues with Modules are in my head, not in the compiler!

Setting up all the things like font and character size etc are best done in a subroutine that you call immediately after SET_GRAPHICS_OBJECT@, then you don't forget any. You can do something similar with Clearwin+ windows for background and style etc - WINIO@ commands can be strung across subroutines.

Eddie