forums.silverfrost.com

[Kenneth_Smith]

Martin,

Obviously, you cannot snap the mouse since that�s the input device.

However, if you have successfully decoded the nearest grid point to the current mouse position (which I assume yesterday�s question was about), instead of the %pl call back writing the current position to the graphics area, it could:

1) draw a symbol at the nearest grid point, e.g. draw_filled_ellipse@

2) write the coordinates of the nearest grid point and other data, offset from the ellipse.

A few points to note:

1. Origin of graphics area is top left, so graphics coordinates work in the 4th quadrant.

2. draw_filled_ellipse@ will draw a filled circle with equal input major and minor diameters.

With this approach, as the user moves the mouse horizontally across the screen a series of circles will appear, giving the impression of the mouse snapping to a grid point.

Ken

[Kenneth_Smith]

This demonstrates the process I described in my previous post. The nearest grid point to the mouse is highlighted and some information related to this is displayed on the screen.

[DanRRight]

[Kenneth_Smith]

Do you really need plot the grid points and hence require to pass the large arrays with the grid points to %pl?

In this example there are just two 2 points to define the full extent of the grid.

Part 1

[Kenneth_Smith]

Part 2

[Kenneth_Smith]

Or if you want to retain the concept of there being a grid around the selected points, something like this perhaps.

[Kenneth_Smith]

Part 2.

[Martin_K]

Ken,

AFTER implementing your code showing the real geodetic X,Y values with the cursor I have a problem with the grid as follows (see picture below): The grid is automatically displayed (the box next to Mrie�ka(Grid) is checked by default). When I uncheck this box (see the picture below, top right), grid will dismiss for a while (10-12 sec.) and then automatically re-appears without my action (and so on around). I tried many changes with no success. I think that it is connected with CREATE_GRAPHICS_REGION@ function. Before implementing the displaying of geodetical coordinates with cursor (when NO CREATE_GRAPHICS_REGION@ was present in the code) it worked (box checked - grid displayed, box unchecked - grid disappeared).

[img]

[/img]

Moreover, after repeating the action 3 times or more, grid is displayed
distorted (see picture below, there are lines displayed and should be only plus signs). I suspect that the %PL code has some problem.
[url]

[/url]

Could you give me a tip what should I check in the code?

[Kenneth_Smith]

Martin,

A few ideas to try:

Examine the integer value returned by COPY_GRAPHICS_REGION@. It should return 1 for success.

Check that the dimensions of the %pl and the internal file you are copying to are the same, X,Y starting at 1 not zero, and the DX, DY values are the same.

Check that you are copying in the right direction to/from the graphics regions.

Try using GRAPHICS_TO_CLIPBOARD@, to check that the internal graphics file is as expected. Immediately after this call you should be able to paste the image into MS Word.

Given that the SIMPLEPLOT_REDRAW@ takes a long time to process the data, there�s always the possibility that the user clicks on another button during this time. It may be worth your while adding a control variable to each of the buttons and radio buttons, so that as soon as one is selected, at the beginning of the corresponding call back all controls are disabled, and only enabled once the current process is completed. The presence of such additional control variables can also help with guiding the sequence of statements in the %pl call back.

The flow of the control statements in the now very complex %pl call back needs to be carefully examined, since all the interactive user actions rely on this part of the code.

Do you have a reduced data set that you can use for testing purposes?

Bebugging code is always time consuming. I changed the order of some statements in some code yesterday and then later observed that one calculated variable was always displayed incorrectly, even although the value returned by print* was correct. Why using %~rf to display the value and a %fl was now being applied because of the change in position. 2 hours to track down the problem.

[Martin_K]

Thanks Ken for your tips.

yesterday I also tried (among other things) just uncheck the box and did absolutely no cursor movement (the cursor was without any movement after unchecking the box, it had no influence on the behaviour of display). Now, I will realize your tips and will inform about the results.

[Martin_K]

Ken,

after a while I would like to inform you that I was able to find and remove the previous mentioned problems (namely that the graphics was always displayed regardless whether there were boxes checked or unchecked).
The problem was that the variable HANDLE_PL - at least, it seems to me so - cannot be setup to a non-zero values (like in your code above) in conjunction with the function COPY_GRAPHICS_REGION@. If so, I could do anything, the graphics was always displayed regardless the fact that the check box for one graph or both was unchecked.

However. now, I am facing another (minor) problem with %PL. ALL graphs are - by default - checked and are also correctly displayed when the function invoking them is invoked for the first time. But, as soon as I uncheck the box(es) and then check it (them) again, the graphic symbol for points (which is + sign, since SYMBOL=12) is (from an inexplicable reason for me) changed (replaced) by a small box as can be seen below:

[url]



If you would have a tip, where could be this problem hidden, I would take a look for it for a while. But this is not so important, so I will let it as is, should I spend long hours to find it. Additionally, it seems to me (as a ClearWin+ beginner) that the %PL command has some internal problem when drawing lines. When I use the option [link=lines] for the points which constitute the state border of the SR, in some areas it connects the points not in turn, but as crossed lines (zick-zack) as can be seen below:

[url]



The points were created by ArcGIS (ArcMap) software, so I checked them with the software again and there is everything OK, all points are smoothly and correctly joined. I double checked with and independent software (Trimble Bussines Center, which I use for my GNSS activities) and there is also everything fine with the points (no crossed lines).
But, I will not lose time with it, since I can use the option [link=none] and then there are no lines (the border is drawn only as points).

Generally speaking, the work with the %PL command has became for me
quite hard partly due to unclear help for its options (such as full_mouse_input), partly due to its current limitations. To put it into another words: the %PL command needs to be significantly improved and there must be added clearly greater flexibility and easy of use, otherwise the way in this direction is very hard and sometimes practically unusable.

Now to my last question: I wanted to start the implementation of your code regarding the showing ellipses with DX,DY values right now, but I stopped at its very beginning. Reason? You have a parameter called N and N=11 (in both variants, I wanted to implement the second one). Later in the declaration you have (among others):

dx(1:N*N), dy(1:N*N) ... xy(1:N*N,1:N*N) ...

However, my N=87312 (grid points only)! So, N*N is a huge number and I think (when I correctly interpret your declarations), it will be not feasible with my value of parameter N (there will be huge numbers). Or something do I not understand correctly?

Thanks!

Martin

[Kenneth_Smith]

Good to see you are making progress.

The combination of checkboxes and two graphics regions was not one I have used or tested before.

Yes there is a problem with symbol = 12 and symbol = 13 when used with change_plot_int@. I questioned Paul about this a few days ago. Solution until a new dll is available is not to use symbol = 12 or 13.

The solution to the big array issue is to organise the input data in a direct access file and use the record number as the index to the data. It will take a while to write the file (but you only need to do this once), and access by record number on a direct file is faster than a user can move a mouse.

locate_i_j_in_table = (i - 1 )*n + j replaces the large matrix.

Example below to demonstrate the idea based on one of my earlier posts.

[Kenneth_Smith]

PART 1

[Kenneth_Smith]

Part 2

[Kenneth_Smith]

Part 3