Help! - plotting REALS using Win32 api's

[isn-removed200637]

I have used QUickWIn to plot data and find the SETWINDOW (which takes REAL arguments) and SETVIEWPORT (for defining the viewport in integer pixels) ideal for scaling from real data( possibly representing real co-ordinates in 2-D space extending from -very large to +verylarge) into the window on the screen. However, I am at aloss when it comes to converting to
doing the same with windows API calls. Windows commands appear to only take integer arguments, and the so-called 'World co-ordinate space' has 2^32 possible values. Do I have to do all my own origin shifting and scaling of my real data to fit into this 'world space' before I can then use the win32 api calls (setwindowextex, setviewportext ex, etc. etc.)?
TIA

[Jugoslav_Dujic]

Yes, that's the limitation of Win32 api calls. In QW, functions come in pairs (RECTANGLE and RECTANGLE_W); in Win32 there is only one set, which always
works with "logical" coordinate system. Logical CS can be set using SetMapMode and SetViewportOrgEx...SetWindowExtEx. Basically, SetMapMode offers the selection of scaling -- MM_TEXT corresponds to QW's "Viewport" CS, while MM_ANISOTROPIC corresponds to QW's "Window" CS. SetWindow* functions make sense only with MM_(AN)ISOTROPIC map modes -- with others, they are simply ignored. If you're doing mixed Viewport/Window drawing, this can be a real PITA since each time you want to switch, you have to save state of Viewport&Window, switch to another system, do the drawing and restore the state. Also, as you saw, you have to cope to convert floating-point values to integers.

Please take another look at the XFTGDI.f90 file I sent you -- it keeps MM_TEXT all the time and internally provides all origin shifting/scaling for you (as QuickWin does). Since these are wrappers, probably it's a bit slower than raw "hand-optimized" Win32, but I think that simplicity outweighs tiny performance loss.

Regards
Jugoslav