forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Native %pl
Goto page Previous  1, 2, 3, 4 ... 18, 19, 20  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5046
Location: Salford, UK

PostPosted: Thu May 04, 2017 2:48 pm    Post subject: Reply with quote

OK. That might be a simple addition. Would it be for the x-axis only and what name would you suggest?
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 633

PostPosted: Thu May 04, 2017 3:37 pm    Post subject: Reply with quote

at the same time and if Ken's suggestion turns out to be easy to implement, as well as having the OPTION of moving the scales (i.e. axes & labels) to the bounding box edges it might be a good idea to have the OPTION to ALSO plot the scales in their 'true' position (as current default) but without labels ?

Regarding Future Wish-List ......
I'm still not personally comfortable with the lack of minor divisions (with or without labels) and the lack of direct GRID lines capability. Those would be definite future enhancements for me. The option to rotate the labels through 90 deg. might also be a future enhancement to be put on the wish list as it would allow some user-control of mitigation of over-crowded labels in some cases.
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 160
Location: Glasgow, Scotland.

PostPosted: Thu May 04, 2017 4:18 pm    Post subject: Reply with quote

Paul, I would suggest both x-and y-axis, the magnetic flux density profile plot I posted on Tuesday suffers the same issue.

Maybe something like:-

Code:

y_crosses = automatic     for current method
y_crosses = xmin          to force y axis to be drawn at the position of minimum x value

x_crosses = automatic     for current method
x_crosses = ymin          to force x axis to be drawn at the position of minimum y value


This should work with and without the frame option.

Plotting this type of data in excel has the same issue in its "automatic" mode and the suggested names are somewhat similar to the terminology used within excel.

Another related thought looking at an excel plot, perhaps a flag to force the x and y labels to be centered on the centre lines of the frame? This would avoid setting [x-axis=@] or [y-axis=@] and having to use a call-back to centre the labels. I have noticed that at present these are always placed centred on the positive part of an axis scale and if all the data being plotted is in the 4th quadrant the y-axis label is omitted. x_label_position = "automatic" or "centre" and the same for the y_label_position perhaps?
Back to top
View user's profile Send private message Visit poster's website
John-Silver



Joined: 30 Jul 2013
Posts: 633

PostPosted: Thu May 04, 2017 10:31 pm    Post subject: Reply with quote

Good suggestion Ken, although looking ahead to when Paul re-visits for enhancements at a later date, a more complete set of options would be:-

left or centre or right justified

on ...

either
+ve or -ve axis
or
on whole axis (for when scales are put on outside bounding box


i.e. 3 x 3 = 9 possibilities ... .for each axis !


In that way the user can avoid as far as possible clashes of axis titles with curves and get the most professional look possible.

Eventualy even by built in user-programming of selection of the option to use based on examination of the data to be plotted maybe ... for those so inclined.

Same argument goes of course for eventual expansion of the main title options of a graphic - complete options would include to allow more than one line for a main title, and place it top or Bottom (or maybe right/left even for some, obviously with rotated text).

All the possibilities of course can be referenced by looking at Excel options as you mention Ken.
As Eddie opten reminds us, we should always have an ear open to existing programs do both as a challenfìge and as a 'brake' on ensuring a certain level of 'consistency' in Windows (and other) best-programming style. (not that everything in windows is good programming style !)
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 160
Location: Glasgow, Scotland.

PostPosted: Fri May 05, 2017 10:22 am    Post subject: Reply with quote

John, your are correct there is an endless list of possibilities depending on the programmer's personal preferences for what "looks good" as well as the nature of the data itself. As soon as I had typed x_crosses = "automatic" / "xmin", the thought struck me why not include a numerical value - which would complicate the programming further. My own %gr based plotting routine which has evolved over the last 5 years now has 70+ optional arguments, and still there a other options which I would like to add for the odd occasion I might use them.

A typical call to this routine looks like this:-

Code:

              call plot(500, igw=400, igh=350, ghandle=2, etched=0, &
                   title = 'Fourier', x_axis_label = 'Time [s]', &
                   y_axis_label = 'Amplitude [pu]', &
                   x_array = x, y1_array = y1, y2_array = y2, y3_array=y3, y4_array = y4, y5_array = y5, &
                   y6_array = y6, &
                   y1_width = 2, y2_width = 2, y3_width = 2, y4_width = 2, y5_width = 2, y6_width = 2, &
                   y1_colour = rgb_deep_pink, &
                   y1_symbol = 4, y1_symbol_size = 5, y2_symbol = 1, y2_symbol_size = 2, y2_colour = rgb_cornflower, &
                   y3_symbol = 4, y3_symbol_size = 5, y3_colour = rgb_english_red , &
                   y4_symbol = 4, y4_symbol_size = 5, y4_colour = rgb_maroon, &
                   y5_colour = rgb_dark_orange, y6_colour = rgb_forest_green ,&
                   y5_symbol = 4, y5_symbol_size = 5, &
                   y6_symbol = 1, y6_symbol_size = 2, &
                   y1_symbol_step = 5, y2_symbol_step = 5, y3_symbol_step = 5, &
                   y4_symbol_step = 2, y5_symbol_step = 5, y6_symbol_step = 5, &
                   autoscale_x = .true., autoscale_y = .true., y1_name ='1', y2_name='5', y3_name='7',&
                   y4_name = '11', y5_name = '17', y6_name = 'Sum', &
                   vertical_grid_line_style = 1, horizontal_grid_line_style = 1, &
                   vertical_grid_line_width = 1, vertical_grid_line_colour = rgb_cornflower, &
                   horizontal_grid_line_width = 1, horizontal_grid_line_colour = rgb_cornflower, &
                   fmt_x_axis = '(F20.4)', fmt_y_axis = '(F20.2)', bold_title = 1, italic_title = 1, &
                   underline_title = 1)


So I am very pleased with the new %pl !


Paul, I do agree with John that grid lines would be a useful longer term addition - there have been grumblings from the guys who use my code since I started using the new %pl as they are used to seeing these.

If you can easily implement the placement of the axis scales external to the frame, and centring of the axis captions this would pretty much guarantee a uniform appearance when different %pl regions are grouped together and for me that would be a big step forward. (I'm probably harking back to the days when I taught engineering drawing - 30 years ago - pen/paper/drawing board, when consistency in appearance is all important).

Thanks

Ken
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 1648
Location: South Pole, Antarctica

PostPosted: Mon May 08, 2017 8:03 am    Post subject: Reply with quote

Paul,

The few grains of salt in ideal %pl i mentioned above are the following. This is what's left to fix in Linear scale, all but may be one are really fast to fix

Let's take this code which plotted almost ideal plot above
Code:
winapp
USE clrwin
integer, parameter :: n_dim = 1153
real*8  X(n_dim), Y(n_dim)
integer(7):: hDib !
integer*4 ilw
character filename*128

      i=winio@('%ww[no_border]&')
      i=winio@('%gr[BLACK]%ff%lw&',660, 550, ilw)

      filename = 'SpectraSampleLinear.bmp'
      hDib = import_bmp@(filename,ires)
      if(ires == 0) ires = dib_paint@(0,0,hDib,0,0)
      call release_screen_block@(hDib)

OPEN (UNIT=275,FILE='A.dat',STATUS='old',err=990)
do i=1,10000
  if(i.gt.n_dim) goto 100
  read(275,*,err=995,end=100) X(i), Y(i)
enddo
100 close(275)
n_points=i-1

      i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&')
      i=winio@('%fn[Tahoma]&')  ! Verdana
      i=winio@('%ts&', 1.9d0)
      i=winio@('%tc&',rgb@(0,0,0))
      i=winio@('%bf&')
      i=winio@('%`bg&',rgb@(250,255,255))
      CALL winop@("%pl[axes_pen=3]")

!     CALL winop@("%pl[SCALE=LOG_LINEAR]")

      call winop@("%pl[framed]")
      CALL winop@("%pl[tick_len=9]")
      CALL winop@("%pl[margin=131]")
      call winop@("%pl[link=curves]") ! link=lines
      CALL winop@("%pl[n_graphs=1]")   
      CALL winop@('%pl[title="Native PL Linear"]')
      CALL winop@("%pl[x_axis='Wavelength (A)']")
      CALL winop@("%pl[y_axis='Intensity (arb.units)@(-5.0)']")
      CALL winop@("%pl[width=2]")
      CALL winop@("%pl[smoothing=4]") ! anti-aliasing
      CALL winop@("%pl[colour=black,style=0,pen_style=0]")   
      CALL winop@("%pl[x_array]")
      CALL winop@("%pl[x_min=12.0]")
      CALL winop@("%pl[y_max=155.0]")
      i=winio@("%pl",770,660,n_points,x,y)

goto 10000

!................. errors ......................
990 Print*, 'Error opening file A.dat for read'
goto 10000
995 Print*, 'Error reading file A.dat'
goto 10000
 
10000 continue
end


If increase image size using mouse you will see the following little problems


1) this problem is obvious
2) Y division is too often, way too many numberings, even though the plot size is very large
3) X division like this must never appear in ideal %PL
Also a bit too many numberings here - 12. May be 12 also would be OK but it have to be integer numbers 12, 13...22
4) This is clearly a much difficult problem: mixture of integer and FP numbers for numbering. I think it is not acceptable
5) Like others also agree the X axis title Wavelength by default has to be centered and moved left and right only at the user request with @(x,y)


Last edited by DanRRight on Mon May 08, 2017 9:08 am; edited 5 times in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1648
Location: South Pole, Antarctica

PostPosted: Mon May 08, 2017 8:06 am    Post subject: Reply with quote

CONTINUE 1

Respect to 2) and 3) above I played with the code Ken found on the net about scales
https://people.sc.fsu.edu/~jburkardt/f77_src/toms463/toms463.html
and found its first two routines SCALE1 and SCALE2 are useful. Let's look specifically for our case above. If we change data in the SCALE1 case (automatically decides which amount of numbers to place within users decided region) there to
Code:
      data n_test / 7, 12, 9 /
      data xmin_test / 12., 12., 0.0 /
      data xmax_test / 22., 22., 155.0 /

we will get    

  SCALE1 chooses a scale for a plot.
       XMIN       XMAX   N      XMINP      XMAXP       DIST Nactual
       12.0       22.0   7       12.0       22.0        2.0       5
       12.0       22.0  12       12.0       22.0        1.0      10
        0.0      155.0   9        0.0      160.0       20.0       8



where first and last case are for ideal numbering of X and Y scales.
Middle case is for X scale i'd call it more verbose amount of numbers like your code is doing today.

So in automatic regime your code must decide which amount of numbers to place on axis based on font size (ideally 5-10) and then run SCALE1 and it will tell exactly what numbers will be placed and their amount. Easy fix.

You can see the SCALE1 program makes exactly ideal step for X axis equal 2, for Y it is 20

In the manual regime which shown in SCALE2 which listens exactly at users defined step (which John also suggested) there must be special option added where user in addition to the existing xmin and xmax, sets the value which TEST02 calls n_test ( better call it increment or step or else. In ideal case above for X step is equal 2, for Y it is 20). Then the user will be responsible for all the garbage he requested Smile. Also an easy fix !

And the last is that if tic mark is not numbered like some on X axis the tic length has to be reduced, say, by 40-50%

And the ideal linear scale %pl is done!


Last edited by DanRRight on Mon May 08, 2017 2:11 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1648
Location: South Pole, Antarctica

PostPosted: Mon May 08, 2017 11:15 am    Post subject: Reply with quote

CONTINUE 2
With LOG all fixable probably even faster

Let's take this code
Code:

   WINAPP
    MODULE modd
    USE clrwin
    INTEGER,PARAMETER::N=65
    REAL*8 X(N),Y(N),Z(N),T(N), U(N)
    !.....................................
    CONTAINS
    !.....................................
    INTEGER FUNCTION callb()
    REAL(2) random
    DO i=1,N
      X(i)=i
      Y(i)=exp(0.35*i) * random()
      T(i)=Y(i)     
      Z(i)=exp(0.7*i) * (random()-0.003)
      U(i)=Z(i)
    ENDDO
    CALL SIMPLEPLOT_REDRAW@
    callb = 2
    END FUNCTION
    END MODULE

    !.....................................
    PROGRAM KKK
    USE modd

    j=callb()
    i=winio@('%ww&')
    CALL winop@("%pl[native]")
!    CALL winop@('%pl[title="Log_linear@(115,299)"]')
    CALL winop@('%pl[title="Title: ideal log_linear@(-15,10)"]')
    CALL winop@("%pl[x_array]")
    CALL winop@("%pl[scale=log_linear]")
    CALL winop@("%pl[y_min=.3]")
    CALL winop@("%pl[y_max=1e7]")
    CALL winop@("%pl[N_GRAPHS=4]")
    call winop@("%pl[framed]")
    CALL winop@("%pl[tick_len=10]")
    CALL winop@("%pl[axes_pen=4]")
    CALL winop@("%pl[x_axis='Wavelength (A)@(-202,2)']")
    CALL winop@("%pl[y_axis='Intensity (arb.units)@(-20,-222)']")

 !  i=winio@('%fn[Tahoma]&')  ! Verdana
    i=winio@('%sf&')
    i=winio@('%ts&', 2.2d0)
    i=winio@('%tc&',rgb@(0,0,0))
    i=winio@('%bf&')

    CALL winop@("%pl[width=3]")
    CALL winop@("%pl[colour=red,link=none,symbol=7]")
    CALL winop@("%pl[colour=blue,link=none,symbol=9]")
    CALL winop@("%pl[symbol_size=8.]")
    CALL winop@("%pl[colour=black]")
    CALL winop@("%pl[colour=green]")
    i=winio@('%pv%pl&', 700,570, N, X,Y,Z,T,U) 
    i=winio@('%ac[Ctrl+Z]&',callb)
    i=winio@('%sf%ts&', 1.d0)
    i=winio@('%ff%cn%^bt[Redraw]%es',callb)
    END

It now looks like this


Obvious small problems


1) obvious out or plotting area at the top and bottom
2) numbering has to be a bit different, not from 0.3 to 3, 30 etc but
from 1 to 10, 100 etc like here which I photoshopped



3) X tics being plotted inside and outside easy to fix. Ideally adding an option tics_in, tics_out, tics_inout like in Origin

4) minor tics do not scale right with major (longer) tics if resize them.
Minor tics have to follow major tics, just always being 40-50% smaller

5) Making parameter N>90 crashes code with message of "argument to EXP out of range". Exp(90) should be perfectly OK with REAL*8 numbers

6) Message offering switch to LINEAR scale from LOG has to react on Esc
(Esc means no switch to linear in this case)

7) Attempt to resize window after launch messing up everything. After Redraw all works fine

VIII) Y caption horizontal position jumps widely when hit Redraw

LOG scale DONE!


Last edited by DanRRight on Mon May 08, 2017 2:11 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1648
Location: South Pole, Antarctica

PostPosted: Mon May 08, 2017 12:01 pm    Post subject: Reply with quote

CONTINUE 3

Here is another, may be better, or at least much more common option for numbering of major LOG tic marks. It looks more homogeneous and easier to implement. (The minor tics choice though does not look good, the %pl existing tics are better)



9) Again, X axis name "Wavelength" like in LINEAR case has to be centered by default. Right justified or moved somewhere has to be user's additional business if needed.

10) "Simpleplot_update" name has to be exterminated from the compiler ! This should be changed to Plot_update@(handle) which changes only the plot marked with specific handle or all open plots if handle is not set or negative

All that will make native %pl 99.9% ideal plotter.

The rest 0.1% can be added later. Some of these ~0.1% I implemented in my own graphics routines and I can share the experience and source code, often just few dozen lines of FTN95 Fortran. Mostly they are like 5 minutes to implement for programmers like Paul still they add WOW factor to the plot and leave all other real time graphics programs light years behind.

For example
- changing symbol size and color according to the Y or X value like in the plots few days back (the ones with the color bar)
- saving graphics into the PNG file PlotYYYYMMDD_hhmmss_ss.PNG and also clipboard
- adding mentioned before grid lines, color bar
- adding error bars (in the form of two numbers (a,b) which are for (+%,-%) from given Y point
- adding Settings menu
- adding move of everything with just Ctrl+mouse (i made that for all axis positions, it's very nice - all using this Fortran)
- adding boxes with the names for curves and symbols like in Crossection vs Deuteron Energy plot above posted few days back. Ability to use Greek letters, subscripts and superscripts
- adding graphics background (also easy to do in Fortran, see below)
- adding shadows to the lines, axis and tic marks
- making fill under the plot, like here



All that will still make 99.99% of ideal

AND the rest 0.01% would be adding an option of keeping all plotting proportions when the user scales the plot size by means of %pv


Last edited by DanRRight on Sat Jun 03, 2017 5:16 am; edited 4 times in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1648
Location: South Pole, Antarctica

PostPosted: Sat May 13, 2017 12:29 pm    Post subject: Reply with quote

CONTINUE 4

Respect to color background used in the last example above, it was so easy to do and was so reliable in FTN77/95 that I made it and forgot for decades. Actually all is done in 5-6 lines of Fortran code after you loaded graphics background tiles. I have demo for it but it is larger then one or two post pages (too harsh restriction), because I also made a GUI and plotted some besier graphics on top. PM me and i will email it to you. Here is just the sketch for this, the rest anyone can do themselves.

Code:

1) count BMP files which will be used used as the graphics backgrounds (tiles). Note that ATTR_files, date_files, time_files are wacky size integer**2 which I always forget and make a mistake, though there may already exist more normal utility as we discussed that here few times

   numbBkgFilesRealyExist = 0
        filePAT = '*.bmp'
        call files@ (filepat, numbBkgFilesRealyExist,  numbBkgFiles, FileNameBkgBMP, ATTR_files, date_files, time_files, file_size)

2) then find their XY sizes and number of colors

       do i = 1, numbBkgFilesRealyExist
         file  = FileNameBkgBMP(i)
         call get_dib_size@(file, ixBkgBMPsize(i), iyBkgBMPsize(i), inb_colours, ier)
         ihDibBkgFile(i) = import_bmp@(file, ires)
       enddo

3) find the XY dimension of the graph where these tiles will be used

        call get_graphical_resolution@(ixGrsize, iyGrsize)

4) and plot background over which you then plot your graphics. The icurBkgDispl is current choice of one of the graphics backgrounds

        do ivert =1, iyGrsize/iyBkgBMPsize(icurBkgDispl)+1
          do ihoriz=1, ixGrsize/ixBkgBMPsize(icurBkgDispl)+1
            i = dib_paint@((ihoriz-1)*ixBkgBMPsize(icurBkgDispl), (ivert-1)*iyBkgBMPsize(icurBkgDispl), ihDibBkgFile(icurBkgDispl), 0, 0)
          enddo
        enddo

Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1648
Location: South Pole, Antarctica

PostPosted: Sun May 21, 2017 6:42 pm    Post subject: Reply with quote

CONTINUE 5

And the final point over i to the native %pl would be adding elements of visual Clearwin+ (which supposedly existed but I never have seen a single example of it. Is it still working and supported ? Pity of not, because this would change the mass perception of Fortran capabilities).

Currently all assembling of the plot has beed done purely by scripting/programming. Nice that adding %pv we can scale the size of the plot with the mouse, but we need more then that. Would be great to add the functionality when the user by pushing some control key like Ctrl or doubleclick can move axis and caption positions etc using his mouse (and possibly the arrow keys on the keyboard) as well as by clicking on the graph call and change all other properties of the plot.

If for example axis margins are set as variables @(ipos, jpos) instead of strict numbers @(33,4) these variables can be saved and used next time. This will make new %pl finally IDEAL tool no one ever had. This is how Fortran must operate. Instead it is currently purely suicidal scripting language leaving the major its advantage - almost natural syntax and almost ultimate simplicity (MATLAB language is Fortran-like and it is currently a simplicity and functionality king, if not yet, it definitely will. Because sadly at some point some morons magnetized people's common sense with the absurd claim that Fortran is just the FORmula TRANslation).

I implemented myself some of such visual functions using Clearwin graphics library in my graphics routines long ago and like this very much. Because this is ultimately exactly how it should be done in the ideal world. This is so easy to do that in comparison the correct tic numbering we are still discussing looks like a tedious job
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Mon May 22, 2017 9:12 am    Post subject: Reply with quote

If I can add my very minor contribution, may I add to the plea for grid lines?

I often draw graphs with the same units on both axes: shear stress on one, direct stress on the other, and Excel doesn't let me set the scale the same for both. That effectively makes the grid exactly square. Excel doesn't plot graphs, but charts.

Eddie
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 633

PostPosted: Tue May 23, 2017 8:10 pm    Post subject: Reply with quote

not quite sure what you mean Eddie, you mean 'square' like this ?

https://www.dropbox.com/s/1uara6r3abzqmor/Ex%20Excel%20Graph%20for%20Eddie%20-1.jpg?dl=0

Maybe I've misunderstd but I had no trouble changing the scales to be equal in Excel.

P.S. graph/chart is semantics ..... e.g. in native %pl a curve is referred to as a graph !!!
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Mon May 29, 2017 11:58 am    Post subject: Reply with quote

The image posted illustrates my issue precisely, because the grid lines define rectangular, not square, boxes. Thus the scales are not the same. The slope of the straight line plotted can be determined by Excel, and if you are interested in, say, y = m x + c, then ‘m’ is readily obtained, even subject to various constraints, such as c cannot be less than 0. Even if you are interested in the line as y = x tan f + c, Excel can give you f in degrees, radians or whatever you want. The issue is that unless the scales are the same, you can’t measure f with a protractor (thus making a trap for student idiots) and if the scales are very different, the visual perception of the angle f is skewed. Working in a field where f has some meaning (calm down dear, this convention was set hundreds of years ago and isn’t my fault), it isn’t a show-stopper, but it gets in the way of instant recognition when you see the printout.

You need equality of scales if, for example, Mohr’s Circle is not to appear as an ellipse.

Not that it matters for an instant when looking on a screen, but the hard copy has the additional shortcoming that the scale isn’t really rational, as in (say) 10mm represents 20 kPa (or 1 inch = 30 psi). Meaning you can’t scale off it easily.

If someone can point me to a way of getting the x and y axis scales exactly the same and rational in Excel, then I would be in their debt.
As to a matter of semantics, of course it is so, and I have defined things to mean what I intend them to mean, a la Red Queen. But Excel’s charts allow you to plot things that obfuscate data relationships as easily as it can clarify them, earning from me the disparaging ‘charts’ (spat contemptuously!) appellation as against the engineer or scientist’s ‘graph’ (spoken in hushed tones with an air of approbation!). Where does this semantics come from? Probably from ‘graph paper’ usually ruled in squares.

Eddie
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 633

PostPosted: Thu Jun 08, 2017 12:47 am    Post subject: Reply with quote

Dan, can you please post the linear problem input file for your linear example in your post on 21st April so I can do a benchmark on my system with dll8 - thanks Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4 ... 18, 19, 20  Next
Page 3 of 20

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group