get_graphics_selected_area

This routine causes me crash. Why it is called in the first place I do not know, the nuc war and bloody hell is going on in this routine pesticiding my slow brain, could also be some interference with the old Simpleplot %pl.

But this Why actually will become not important if there exist the way to avoid this crash by testing first if graphics area is selected or not and then chose to call or not this routine. Any suggestions?

This routine will raise a runtime exception 'No active graphics block in selection mode' if there is currently no graphics object selected. This is the same graphics object as in select_graphics_object@. It relates to the %gr options box_selection, line_selection and free_selection. So it means that the %gr region has not been created or no longer exists.

Strange thing is that there are plenty of %gr windows open when crash takes place, and even one graphics window which is always on till program shutdown. Is there a way to check if any graphics window is open? Crash takes place only after use of %pl (opening and closing them several times)

As a general rule, if you have more than one 'graphics object' open (such as a %gr or a native %pl) then you will need to use an identifier and make calls to select_graphics_object@ before calling routines that process a graphics object.

For example, if you have an existing %gr, leave it open and create a temporary native %pl, then you will have problems when you close the temporary %pl and go back to the existing %gr.

I have added code to the ClearWin+ library that hopefully fixes this particular scenario but for safety it is better to use a %gr identifier.

As usually many thanks for fixing, Paul. Yes, this is what most probably happening. This all worked i'd say semi-amicable for decades and only started after I made one plot using native %pl recently.

From my side i will try to find the handle of the %gr window mouse is clicking on. if this does not fit any existing handles then the program will just ignore calling get_graphics_selected_area

Dan,

This all relates to a post I made years ago called 'When is a handle not a handle?'. Mostly, when you get the handle of a control it is an integer number drawn from a pool of Windows handles. Graphics objects are different: you GIVE a graphics object a handle at the moment of creation. This is NOT a Windows handle. Paul is using 'identifier' now, but the word 'handle' is used in the documentation.

As you gave each graphics area life, you should have selected that unique identifier to give it, and that is the one you use in 'SELECT_GRAPHICS_OBJECT@. You should know all the handles and what they relate to.

A problem with Clearwin's %gr is that you can create a graphics area without giving it a handle. Do that more than once, and you are stuck. Sometimes it seems useful, like the woman with 14 children all called 'Wayne' (so they would all come if called) - but in practice it is a bad idea. Clearwin in my experience deals with the last created %gr area when you immediately afterwards give graphics commands, but it can get confused if you do other things and then return to a graphics area.

You should only use GET_GRAPHICS_SELECTED_AREA@ when you absolutely know that the user with select a graphics area as his/her next interaction with the program, for example when they have clicked on a button that tells the program you want to select an area. It is not like some graphics programs like CorelDRAW where you can select an area whenever you feel like it, and the program responds appropriately.

If you want the CorelDRAW type functionality, you have to use full mouse input and deal with it yourself, decyphering what the user wanted from the sequence of clicks.

Perhaps it would be convenient for Clearwin+ to have a routine that listed all graphics handles and which is the current one, but if you don't provide the handles in the first place, it wouldn't work very well!

Eddie

Dan,

This all relates to a post I made years ago called 'When is a handle not a handle?'. Mostly, when you get the handle of a control it is an integer number drawn from a pool of Windows handles. Graphics objects are different: you GIVE a graphics object a handle at the moment of creation. This is NOT a Windows handle. Paul is using 'identifier' now, but the word 'handle' is used in the documentation.

As you gave each graphics area life, you should have selected that unique identifier to give it, and that is the one you use in 'SELECT_GRAPHICS_OBJECT@. You should know all the handles and what they relate to.

A problem with Clearwin's %gr is that you can create a graphics area without giving it a handle. Do that more than once, and you are stuck. Sometimes it seems useful, like the woman with 14 children all called 'Wayne' (so they would all come if called) - but in practice it is a bad idea. Clearwin in my experience deals with the last created %gr area when you immediately afterwards give graphics commands, but it can get confused if you do other things and then return to a graphics area.

You should only use GET_GRAPHICS_SELECTED_AREA@ when you absolutely know that the user with select a graphics area as his/her next interaction with the program, for example when they have clicked on a button that tells the program you want to select an area. It is not like some graphics programs like CorelDRAW where you can select an area whenever you feel like it, and the program responds appropriately.

If you want the CorelDRAW type functionality, you have to use full mouse input and deal with it yourself, decyphering what the user wanted from the sequence of clicks.

Perhaps it would be convenient for Clearwin+ to have a routine that listed all graphics handles and which is the current one, but if you don't provide the handles in the first place, it wouldn't work very well!

Eddie

Eddie, I hope Paul fixed somehow the issue which will prevent get_graphics_selected_area from crash. Crashes are unacceptable from my fox hole in South pole. Imagine this is a heart monitor and it crashes.

Dan

What can I do? The program asks for the size of a rectangle in an unspecified %gr. How can ClearWin+ and your program recover from this situation?

I could provide a function that supplies the identifier of the active 'graphics object' (if there is no way to get this at the moment). But either way you would still have to fix your code.

Equally an error code could be supplied in some way but again your code would need changing to test for this and to do something when the error condition is encountered.

Paul,

My diagnosis is that Dan has multiple %gr regions without handles / identifiers. The normal situation is that graphics is/are written to the last-created %gr region. If GET_GRAPHICS_SELECTED_AREA@ is different in this respect, perhaps that is the first thing to look at. Maybe it relates somehow to the native %pl.

As for Dan, my recommendation is to go through the source code and give each %gr an identifier, and keep the list in (say) an array in a named COMMON block. It wouldn't be too hard to also update (for programmer use) a variable indicating which is the current one.

The instructions in FTN95.CHM are absolutely clear, if more than one graphics surface is to be drawn, that identifiers are needed along with the grave modifier. Perhaps that needs to be enforced.

Changes which enforce strictness have the potential to upset some existing codes, but is it too difficult to create a warning if an attempt is made to create multiple graphics regions with the same (or non-existent) handle? Or to inhibit GET_GRAPHICS_SELECTED_AREA@ if such a situation exists?

Eddie

Eddie

In some contexts (like the present one) it would be possible to ignore the error and return [with say (-1,-1,-1,-1)] but that may not please everyone or even anyone. There would have to be a flag to set that says you want this behaviour and then it would only work in cases like this one when the error occurs at the top level of a library routine.

Even then it would be a major task to go through the library and identify every situation where this would be possible. In my opinion there are more urgent and important things that are waiting to be done.

I don't see how my code can be fixed. Let's look at the situation: multiple graphics %gr windows with and mostly without identifiers are opened. Then the native %pl window is opened and closed. You click on one of graphics windows and booooom - crash. What identifiers can give you in this case? I don't see how they can be used. It is not the Select_Graphics_Object decides but your mouse pointer which window to be current. There exist facility to identify window handle but no facility which will identify current graphics window identifiers under mouse.

My general suggestion for all to discuss here would be ones and for all forbid Get_Graphics_Selected_Area and any other %% controls from crashing and in case of any problems just do nothing or also leave plain text (or better Windows' style automatically disappearing in couple seconds, Eddie will like this, me too) warnings. I'm ready to test this idea on Get_Graphics_Selected_Area before broad changes which definitely will take developers' time

I will try to add Select_Graphics_Object just before Get_Graphics_Selected_Area in the case where identifiers exist and see if this works.

Dan

I have made a change to the ClearWin+ library that might solve your particular problem.

With this change, when you open and close a temporary native %pl (or %gr), hopefully the 'current graphics object' will be restored to what is was before.

If you can wait a couple of days, I will upload a new set of DLLs for you to try.

Alternatively you must attach a grave accent to %gr and supply an integer value as the identifier for the %gr. Then use this value in a call to select_graphics_object@ before calling get_graphics_selected_area@.

It's OK, this is not urgent issue, Paul.