Feature needed in Qwickwin graphics

Feature needed in Qwickwin graphics

I'm trying to convert some old code that did extensive line graphics using an old obsolete library (Halo). Have made much progress, however I am surprised to learn that, apparently, the Qwickwin library, while it supports all manner of line drawing functions (Lineto, polygon, etc.), none of them support a line width other than the minimum 1 pixel. I need to draw lines of varying weights, say at least 2, 3, 5, 7 pixels.

I can't see any way to do this, other than to call the Windows functions instead, which means setting up pen handles, etc. Is this the best alternative available to me? Can anyone help me get started, or suggest an alternate?

I have actually written a functional replacement for Lineto, using Qwickwin routines, that draws a filled rectangle (long, very thin, 4-node polygon) as a substitute for the simple, 1-pixel-wide line. But surely there must be a better way.

Daryl

21 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Wendy Doerner (Intel)'s picture

Daryl,

This (changing the width of a line in Quickwin)has been requested from our compiler before. I will associate this forum post with the request so if it is implemented you will be informed.

------

Wendy

Attaching or including files in a post

Thanks for responding, Wendy. Though not quite the response I was hoping for; I would rather learn that I had overlooked something, or that there was a good known workaround.

So I am pursuing thecalling of the API functions for lineto, polygon, etc. I have to learn the lingo for creating a pen, selecting the pen, etc.

The on-line documentation strongly hints that this is possible from Quickwin (e.g., it warns I have to rename the functions MSFWIN$LineTo, etc), though I can find no good examples to follow. My experimentation so far does not work. And, Lawrence's book clearly states that these API calls cannot be used from Quickwin.

Can someone advise? I don't want to bark up this tree any more if it's not going to get me anywhere.

Daryl

Yes, please add this capability - I have been waiting for 12 years though so maybe it will not happen soon!

Wendy Doerner (Intel)'s picture

Yes I have added your requests to the feature request which should help lobby for its inclusion in a future release. It just missed the cut for 12.0 though.

Wendy

Wendy Doerner (Intel)'s picture

This has been added to our 12.1 Update 7 release which you can download from registrationcenter.intel.com. Here is the documentation on how to use this new feature.

------

Wendy

Attaching or including files in a post

SETLINEWIDTHQQ

Subroutine

SETLINEWIDTHQQ (W*32, W*64)

Graphics subroutine: Set the width of the (solid) line drawn using any of the supported graphics functions.

Module

USE IFQWIN

Syntax

CALL SETLINEWIDTHQQ(x)

Where,

x is of type INTEGER and represents any scalar integer in value.

Results

Sets the line width to the scalar passed as argument.

SETLINEWIDTHQQ affects the drawing of straight lines using functions - LINETO, POLYGON, LINETOAR, LINETOAREX, RECTANGLE and that of curved lines as in ARC, ELLIPSE, or PIE.

Compatibility

Standard Graphics Quickwin Graphics Lib

GETLINEWIDTHQQ

Function

GETLINEWIDTHQQ (W*32, W*64)

Graphics function: Get the current line width or the line width set by the last call to SETLINEWIDTHQQ.

Module

USE IFQWIN

Syntax

result = GETLINEWIDTHQQ()

where,

result is of type INTEGER. The result contains the current width of the line.

Default behavior

If there is no call to SETLINEWIDTHQQ in the program (or on that particular graphics window), it returns 1. (The default width of a line drawn by any graphics routine is 1 pixel.)

Compatibility

Standard Graphics Quickwin Graphics Lib

Current Limitation

ThenWidthargument in the CreatePen() API is the width used to draw the lines or borders of a closed shape. A cosmetic pen can have a width of only 1 pixel. If you specify a higher width, it would be ignored. A geometric pen can have a width of 1 or more pixels but the line can only be solid or null. This means that, if you specify the style asPS_DASH,PS_DOT,PS_DASHDOT, orPS_DASHDOTDOT but set a width higher than 1, the line would be drawn asPS_SOLID.

http://msdn.microsoft.com/en-us/library/dd162797(v=VS.85).aspx

onkelhotte's picture

Wow, thats great! Thanks a lot.

Ditto, thanks, it works great!!

Neels

Hooray! I'm impressed, because
(1) I can now draw lines of variable width without resorting to my clumsy (and imperfect) workaround.
(2) We talked and Intel listened.
(3) Quickwin is not dead (I hope).

I'm surprised though that this new function is not covered in the online documentation, or even in the release notes. Makes me wonder--has anything else been added that we don't know about?

Is Intel really committed to improving Quickwin? I have a modest list of enhancements (as I'm sure others do) and it would be nice to know if there is any hope...

Wendy Doerner (Intel)'s picture

Sorry we missed including it in the documentation/release notesfor 12.1, it will be in the next release documentation. Yes post any feature requests for Quick Win and we can submit them for consideration.

------

Wendy

Attaching or including files in a post

Here's my immediate, short list of feature requests for Quickwin:

1. A fast console window.
2. Windows for which vertical and horizontal scrollbars can be obtained independently, as each is required, instead of both-or-nothing as we have now.
3. Some pre-packaged, ready-to-go common dialog boxes (e.g. GetOpenFilename, GetSaveFileName, colorpicker, fontpicker)--and include optional arguments to control where these boxes appear on the screen.
4. Ability to save a graphics window capture in vector format (emf file) in addition to the bitmap format (bmp); also a converter from bmp to tif or gif.

That's it for now. I'm sure many others have their pet peeves and will add to this list.

I have a few requests that is currently achieved using Xeffort but I worry about how long Yugoslav will maintain Xeffort:

1. The capability to switch the visibility of controls on and of: RetLog = DlgSet(DLG, IDC_Button_Map, .False., DLG_Visible)

2. Scrollable dialog boxes - with the mixture of todays users having anything between a 14" screen and a 27" screen with varying resolutions it is impossible to make dialog boxes that fits all unless they are scrollable.

Neels

For 1. Try ShowWindow(GetDlgItem(dlg%hwnd,IDC_CONTROL),SW_HIDE)

Wendy Doerner (Intel)'s picture

Thanks for the ideas on feature requests. I will be filing them and then posting the engineering numbers to track here when any discussion on their merits is concluded. I want to be sure to include any comments from multiple customers.

------

Wendy

Attaching or including files in a post

onkelhotte's picture

Hereare someother suggestions:

- Enable the close dialog box of graphics windows. Why are only minimize and maximize shown?

- When you are drawing a lot you get a "flickering" image. Someone here (I think it was yugoslav) told me this is because QuickWin renders every codeline immediately. Useful would be something like this:

call initVirtualScreenQQ(unit)
! ...
! doing a lot of drawing operations
! ...
call renderVirtualScreenQQ(unit)

So QuickWin gathers all information what should be drawn im memory and then send it to the screen

- coloring Edit Control background and text

- adding a transparent (alpha) value for colors, an ARGB value instead of just RGB

Thats what comes to my mind... The most important thing for us would be the VirtualScreenQQ enhancement because this flickering is very annoying.

Markus

I agree with this. Even if all I want to do is open a window at a particular location--it must first appear at a default location, then I have to move it. This is flicker. Annoying.

Any chance you might contribute your Halo replacement library to the forum? I had to do the same recently this year, but did a crude conversion that lost some of the functionality, as we had long thrown out the Halo documentation to know exactly what some of the routines did.

I will certainly consider this, HOWEVER--

What I have is not at all a general Halo replacement. It's just the library that we developed, using Halo, to do general-purpose xy graphs. And it's not nearly as general-purpose as some other libraries, but we like it because (1) it is tightly integrated with Fortran code (you don't have to print your data to a file and then call up an independent routine to plot it), and (2) it can do some important things that other plotting applications can't.

It's some time before this could be released, but I'm glad to know of any interest.

Wendy Doerner (Intel)'s picture

The Engineering tracker number on this set of feature requests is:DPD200178323. Will update this thread if any get implemented or engineering needs more information.

------

Wendy

Attaching or including
files in a post

Any updates on these requests?

Neels

app4619's picture

@Neels " I agree with this. Even if all I want to do is open a window at a particular location--it must first appear at a default location, then I have to move it. This is flicker. Annoying."

I wrote a simple routine using API SetWindowPos , you can then set the dialog position before it is displayed. It used to really irriitate me because I have some dialogs that frequently open and close and having moved them manually to a good location they then used to go back to the default position. I used getwinpos to save the last known location of my dialogs on close and use this next time they are popped.

Login to leave a comment.