Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Feature needed in Qwickwin graphics

dboggs
New Contributor I
2,227 Views
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
0 Kudos
20 Replies
Wendy_Doerner__Intel
Valued Contributor I
2,183 Views
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

0 Kudos
dboggs
New Contributor I
2,183 Views
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
0 Kudos
Neels
New Contributor II
2,183 Views
Yes, please add this capability - I have been waiting for 12 years though so maybe it will not happen soon!
0 Kudos
Wendy_Doerner__Intel
Valued Contributor I
2,183 Views
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
0 Kudos
Wendy_Doerner__Intel
Valued Contributor I
2,183 Views
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

0 Kudos
onkelhotte
New Contributor II
2,183 Views
Wow, thats great! Thanks a lot.
0 Kudos
Neels
New Contributor II
2,183 Views
Ditto, thanks, it works great!!

Neels
0 Kudos
dboggs
New Contributor I
2,183 Views
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...
0 Kudos
Wendy_Doerner__Intel
Valued Contributor I
2,183 Views

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

0 Kudos
dboggs
New Contributor I
2,183 Views
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.
0 Kudos
Neels
New Contributor II
2,183 Views
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
0 Kudos
anthonyrichards
New Contributor III
2,183 Views
For 1. Try ShowWindow(GetDlgItem(dlg%hwnd,IDC_CONTROL),SW_HIDE)
0 Kudos
Wendy_Doerner__Intel
Valued Contributor I
2,183 Views

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

0 Kudos
onkelhotte
New Contributor II
2,183 Views
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:

[bash]call initVirtualScreenQQ(unit)
! ...
! doing a lot of drawing operations
! ...
call renderVirtualScreenQQ(unit)
[/bash]

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
0 Kudos
dboggs
New Contributor I
2,183 Views
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.
0 Kudos
bendel_boy1
Beginner
2,183 Views
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.
0 Kudos
dboggs
New Contributor I
2,183 Views
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.
0 Kudos
Wendy_Doerner__Intel
Valued Contributor I
2,183 Views
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.
0 Kudos
Neels
New Contributor II
2,183 Views

Any updates on these requests?

Neels

0 Kudos
andrew_4619
Honored Contributor III
2,054 Views

@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.

0 Kudos
Reply