forums.silverfrost.com

[DanRRight]

Thanks Paul, indeed, the dx and dy allows the fine tuning of amount of numbering labels. I updated the code above on page 15 to include the dx and dy steps

[DanRRight]

UPDATE.
After further play with this feature i found that it only worked for this specific sizes around 900x600. When i took much larger plot size for example 3600 x 2000 (initially or after resize using mouse) the program forgets this 0.1 step and starts to behave like before, placing large amount of numbers with smaller then user requested dx and dy steps.

I understand that if labels become too crowded that they start to overlap the code should decrease their amount up to just one label or even zero for very small thumbnail images, but for larger images the dx=fval and dy=fval have to stay as user requested, in our example dx=0.1, dy=0.1

Also is it planned to have something like this to update dynamically ?

[DanRRight]

John,
1) I have no problems that even if dx, dy are set by the user - on the plot they are flexible. This flexibility is needed because when you shrink the size of plot the numbering eventually will be too crowded (which again requires very good universal label placement which works without dx, dy).
But when the spacings between numbering labels are OK and you increase plot size there is no reason for code to modify spacing the user intentionally set to adjust better numbering
2) Does my code work like that (showing nothing) for all sizes? I ran it and it works OK no matter what size.
3) Added %nr.

Paul,
Looks like get_plot_point@ has a bug. Look at this code which plots line from min left to max right of screen. Code places point at (X,Y) = (1,1). Try to change limits in small range and see all is OK until min values become positive

[PaulLaidler]

I can't see a problem at the moment.
Which "min values" are you referring to?

[Kenneth_Smith]

Paul,
Apologies for raising this again, but can I reiterate my suggestion for an option to place the text for the scales external to the frame. It's one limitation of the present %pl which I cannot devise a "work around" before the call to %pl, and it really spoils plots like this one.



In this example I am drawing the circles after the plot is formed (there is an invisible graph plotted first to establish the frames).

A quick fix is to use set_opacity@(128) but that results in the plot looking rather "wishy - washy" as we say in Glasgow.

I do have an idea of how I could fix this - but it involves generating two other plots and copying the graphic areas containing the scales into the final plot in which the scales have been suppressed by making the text the same colour as the back-ground - all a bit messy. Hence my gentle reminder.

I cannot simply set the text colour to white before the call to %pl, and add the scale text via the call back as the user specified dx and dy values are not always used.

Same plot, using set_opacity@ tricks:-



It's OK, but external scales would be better

Thanks
Ken

[DanRRight]

[PaulLaidler]

Dan

Can you check the code that you have posted. I may be missing something but I don't think it does what you say. Try running it after copying it back to your computer.

Ken

I have noted your request. In the meantime one way to fix the presentation is to draw the axes with an offset.

[PaulLaidler]

Dan

I have tried to work out what your program is intended to do but I can't make it out. It plants an "ellipse" at (1,1) and the range for the axes is changed via %rf edits. But the changed values are not implemented in the drawing of the graph.

If, in your version of the program, the "ellipse" is not drawn when the xAxisMax value goes negative then that is what should happen.

Apart from the fact that the program is not functional, the only error I can see is that the parameters graph1 (=1) and link_none (=0) have not been defined or set.

[DanRRight]

Paul,
I checked the code above and all works like i described.
Not sure undefined variable was important and not sure i fixed this undefined error correctly, but there is no undefined errors right now in little bit edited code below.

Now i hope that all users with older then 8.20 versions can reproduce this bug as i commented two lines setting dx= and dy=. This compiler needs more active users, this will help its development.

Do the following: for simplicity do not change anything but Xmin

1) When start the code do you see the red dot at X=1, Y=1 ?
2) Change Xmin to -3. Do you see that the red dot still stays at the same point ? Same with Xmin=-2 or -1 or -10.
3) Now set Xmin=1 . Do you see red dot moved to X=2 while it must stay still at X=1? DONE

You may play further and see that at Xmin=2 the red dot moved to 3.
You may also edit the code and set position of red dot at any place, for example at 3,3

[PaulLaidler]

Dan

I haven't worked out exactly what is wrong with your code. Either it's related to the order that the callbacks are called or maybe a callback is being called from a callback. If the latter then perhaps PERMIT_ANOTHER_CALLBACK@ might fix it. Anyway here is a modified version of your code that does what I assume you want.

[DanRRight]

Paul,
I see exactly the same problem in you code. The doubledevilry ... like the two headed ridge nearby called Diablo

All,
Please check that if you increase Xmin > 0.5 the red dot moves instead to stay still at x=1 like it should

[DanRRight]

Thanks, John. Letters jammed are OK. I see last month Paul started with scaling option, hopefully he will complete it in the future so that scaling will work with all elements of the plot (text sizes, borders, line widths). Right now it scales only plotting area, as i remember

This message is to all,
Can you please run my code in the page 17 choosing "PL" option gradually decreasing the size of plotting area to zero ? Do you see that the ring pattern is plotted OK? I see all OK, John gets empty plotting area

[PaulLaidler]

Things are beginning to make sense...

On a different thread http://forums.silverfrost.com/viewtopic.php?t=3505 you will find a reference to unwanted callback reasons "?". One way that these occur is when an action in a callback function leads to another callback function being called. This malfunction is now blocked in the latest ClearWin+ that I am using and which has not yet been released.

This means that you will be getting a different experience from me. It also means that the root problem is (almost certainly) that of one callback leading immediately to a call to another (or worse still) a call to itself.

You might observe this by tracking the callback reason but I suggest that you put this issue on the back burner until you get the next release of the ClearWin+ library.

[Kenneth_Smith]

Paul,

Another one for you to look at I am afraid. GET_PLOT_POINT@ only works properly if the range between xmin and xmax spans zero, and the range between ymin and ymax also spans zero.

The following code illustrates the issue. With the initial values, the point is drawn at the correct coordinates (0.5,0.50), but if you change xmin to 0.5 for example, the point is incorrectly drawn at (1.0,0.5). Same occurs with the y axis.

Regards

Ken

[Kenneth_Smith]

Problem solved. get_plot_point2 demonstrates that I thought GET_PLOT_POINT@ would do. Note that you need to explicitly know xmin for this to work.