Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I

dialog graphics

Jump to solution

I realize that the Intel compiler in C++ would allow you to draw a graphic within a modal dialog box but can Fortran also do that and if so, what  object can I draw into?

Thanks,

Brooks Van Horn

0 Kudos

Accepted Solutions
Highlighted
Valued Contributor II

As a partial response #11 and

Jump to solution

As a partial response #11 and #12, item 2 is quite trivial e.g. the following routine (with only 1 function line of code) would do that with quickwin dialogs. 

subroutine dlg_SHOWHIDE(dlg, ID, LVISI, iret )
    use Ifwin, only: dword, ShowWindow, GetDlgItem, SW_SHOW, SW_HIDE
    use iflogm, only: dialog
    implicit none
    type(dialog), intent(in)    :: dlg   ! alreday initialised quickin dialog 
    integer, intent(in)         :: ID    ! resource ID
    logical, intent(in)         :: Lvisi ! .true. to show, .false. to hide the control of ID
    integer(dword), intent(out) :: iret  
    !If the window was previously visible, the return value is nonzero.
    !If the window was previously hidden, the return value is zero.
    if( LVISI) then
        iret = ShowWindow (GetDlgItem(dlg%hwnd, ID), SW_SHOW) 
    else
        iret = ShowWindow (GetDlgItem(dlg%hwnd, ID), SW_HIDE) 
    endif      
end subroutine dlg_SHOWHIDE

I don't agree with Paul that QuickWin is pointless, I think it allows some windows look and feel to a program that requires a lot less knowledge (=time) to get started than using the Windows API in full. The windows API is not difficult to use but there is much more time investment needed to getting started. There are many scientist and engineers that 'do a bit of programming' as a small part of their job and the Quickwin approach meets those needs as they simpily would not otherwise have the time to invest.  Quickwin does not do everything the API can do and if it did it would be missing the point of its existance as a 'simplified' interface.

 

View solution in original post

0 Kudos
22 Replies
Highlighted

The compiler has nothing to

Jump to solution

The compiler has nothing to do with this. Can you point to a description of the C example you saw?

Retired 12/31/2016
0 Kudos
Highlighted
New Contributor I

It's been a while Steve and

Jump to solution

It's been a while Steve and memory is not as good as it once was. But I seem to remember that it was using one of the other dialog controls, like picture controls -- maybe subclassing a picture control. When will we get the full capabilities for dialogs that a C++ programmer can use?

Brooks

0 Kudos
Highlighted
New Contributor I

You're right, the compiler

Jump to solution

You're right, the compiler proper doesn't have anything to do with the controls but Intel's implementation of using MSVC as your GUI does.

0 Kudos
Highlighted
New Contributor I

Steve, does Intel have a

Jump to solution

Steve, does Intel have a template or code snippet for creating a modal dialog that we can use to extend the capabilities of our apps?

Brooks

0 Kudos
Highlighted
New Contributor I
0 Kudos
Highlighted

Pretty much anything C can do

Jump to solution

Pretty much anything C can do, Fortran can do. You can open the resource editor and add any kind of control, including a picture control. That chart control you linked to is a C++ class library, but I'm sure that under the hood it is using standard Windows control APIs. 

The Intel Fortran IFLOGM dialog box feature doesn't support picture controls, but you can use the Windows API to do it. Also check out Jugoslav Dujic's Xeffort, which I am now hosting.

Retired 12/31/2016
0 Kudos
Highlighted
New Contributor I

I use Xeffort to draw

Jump to solution
I use Xeffort to draw pictures (graphs, schematics etc.) in a dialog.
0 Kudos
Highlighted
New Contributor I

Thanks boyh. I think I'll

Jump to solution

Thanks boyh. I think I'll evaluate the Xeffort code.

Brooks

0 Kudos
Highlighted
New Contributor I

I downloaded Xeffort and

Jump to solution

I downloaded Xeffort and tried to install. Installation said my IVF was not integrated into MSVS 2013 but it is. I have IVS XE 2016 R3. I went ahead with the install but it didn't really do anything. I also installed the help files and they don't work either. I'm running Win 10 Enterprise with all updates on an Intel I7-4770 with 32 GB RAM. C-Drive is 150GB SSD and D-Drive is 2 TB SATA. End result, I don't think Xeffort will be a good product for the future.

Brooks

0 Kudos
Highlighted
New Contributor I

I primarily use three

Jump to solution

I primarily use three utilities from Xeffort:

1. Dialog boxes that add scroll bars if they are bigger than the screen display area

2. The option to easily display or hide any dialog control, radio button, edit box etc

3. The option to create an area in a dialog to write to, draw to, add a picture to.

If Intel add these options to Qwin I will no longer use Xeffort. But it seems very low on the priority list, if it is even on there.

0 Kudos
Highlighted
New Contributor I

I too would like to have the

Jump to solution

I too would like to have the three features you mention, along with many others that should be a natural extension to Quickwin. I use Quickwin a lot but am often frustrated by the apparent lack of commitment by Intel. Quickwin is one of the main reasons I use IVF, and it may be the main reason I abandon it if development doesn't continue--or some other sign of life is shown.

0 Kudos
Highlighted
Valued Contributor I

"Cocaine makes you a new man.

Jump to solution

"Cocaine makes you a new man.  And the first thing a new man wants is more cocaine."  - Robin Williams

Once you start writing Windows GUI programs, you only want more and more atomic control over Windows features.  Quickwin is an abstraction layer, designed (I infer) to provide console output with a minimum set of windows-like features while removing from the programmer the obligation to actually know or learn much about how Windows programming really works.

The solution to @dboggs' and others' problems encountering the limits of Quickwin is to ditch the Quickwin and invest some effort to learn how to code directly using the Windows API.  Doing this from a 100%-Fortran program is exactly the same -- not easier and not more difficult -- as from any other language.  Intel provides a set of WinAPI interfaces and constants which are very largely complete, and a one-line INCLUDE is all that is needed to make every WinAPI instantly available.

Suggestion: get yourself a copy of one of Petzold's pre-MFC books and work throught it, translating from C to Fortran on the fly, which is very easy.  That is how pretty much everyone has learned Windows programming, takes a few months to get the message, but once you are there it becomes natural and rewarding.

Intel has done itself and the Fortran community a profound dis-service by providing Quickwin at all, since Quickwin allows programmers to pretend they can continue to live in the distant past, whereas Fortran can easily take its place among modern GUI-supporting languages. The problem is not Quickwin, it is programmer laziness. 

0 Kudos
Highlighted

QuickWin came from Microsoft.

Jump to solution

QuickWin came from Microsoft. It has its uses - especially when one wants to take an existing Fortran console application and add a bit of Windows GUI feel to it. QuickWin was never intended as a complete replacement for programming using the Windows API and we don't intend to enhance it further.

There are two other Fortran-friendly GUI APIs available, GINOMENU and Winteracter. If you need more capability and don't want to go straight Windows API, they are worth a look. 

Retired 12/31/2016
0 Kudos
Highlighted
Valued Contributor II
1 View

As a partial response #11 and

Jump to solution

As a partial response #11 and #12, item 2 is quite trivial e.g. the following routine (with only 1 function line of code) would do that with quickwin dialogs. 

subroutine dlg_SHOWHIDE(dlg, ID, LVISI, iret )
    use Ifwin, only: dword, ShowWindow, GetDlgItem, SW_SHOW, SW_HIDE
    use iflogm, only: dialog
    implicit none
    type(dialog), intent(in)    :: dlg   ! alreday initialised quickin dialog 
    integer, intent(in)         :: ID    ! resource ID
    logical, intent(in)         :: Lvisi ! .true. to show, .false. to hide the control of ID
    integer(dword), intent(out) :: iret  
    !If the window was previously visible, the return value is nonzero.
    !If the window was previously hidden, the return value is zero.
    if( LVISI) then
        iret = ShowWindow (GetDlgItem(dlg%hwnd, ID), SW_SHOW) 
    else
        iret = ShowWindow (GetDlgItem(dlg%hwnd, ID), SW_HIDE) 
    endif      
end subroutine dlg_SHOWHIDE

I don't agree with Paul that QuickWin is pointless, I think it allows some windows look and feel to a program that requires a lot less knowledge (=time) to get started than using the Windows API in full. The windows API is not difficult to use but there is much more time investment needed to getting started. There are many scientist and engineers that 'do a bit of programming' as a small part of their job and the Quickwin approach meets those needs as they simpily would not otherwise have the time to invest.  Quickwin does not do everything the API can do and if it did it would be missing the point of its existance as a 'simplified' interface.

 

View solution in original post

0 Kudos
Highlighted
New Contributor I

I appreciate Paul's comments

Jump to solution

I appreciate Paul's comments but he presumes that Quickwin users are only in it for the Windows API calls. This is far from the truth. The biggest reason I use it, for example, is for the graphical primitives tools. We have a sophisticated library for drawing xy graphs based on these primitives that was developed over the last 30 years, and the last thing I ever want to do is convert it all to Windows API.

Also, if I were a professional programmer, I probably would take the time to learn Windows programming. But I am only an engineer who needs to write programs to get a job done. I cannot afford to take the time to learn how Windows works. I fear I would be on Linux or something else entirely before I made significant progress.

0 Kudos
Highlighted
New Contributor I

Also, if I were a

Jump to solution

Also, if I were a professional programmer, I probably would take the time to learn Windows programming. But I am only an engineer who needs to write programs to get a job done. I cannot afford to take the time to learn how Windows works. I fear I would be on Linux or something else entirely before I made significant progress.

I agree. The time to learn Windows programming is, for me, far better spent learning OpenMP.

0 Kudos
Highlighted
New Contributor I

Hi.

see here for an example posted by yours truly when he was still using Compaq Visual Fortran (the code was subsequently adapted with minimal adjustment to the Intel Composer)

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/276677

You are certainly not the first to raise this subject.
You can find other similar links just by using the 'Search' box capability above  using 'draw on dialog controls' as the keyword phrase.
 

0 Kudos
Highlighted
New Contributor I

Anthony, that is a good start

Jump to solution

Anthony, that is a good start but it is not a working model. Even the _2 version and especially if you're usinf IVF and not CVF.

Brooks

0 Kudos
Highlighted
Black Belt

Brooks, if it will help, I

Jump to solution

Brooks, I attach a makefile that I exported from CVF 6.6C and modified to work with IVF 16.0.3. I built the debug and release versions out of the source files in https://software.intel.com/sites/default/files/f2/81/dfspg_2.zip with the commands

nmake -f ownerdraw.mak CFG="OWNERDRAW - Win32 Debug"
nmake -f ownerdraw.mak CFG="OWNERDRAW - Win32 Release"

The resulting EXE files ran normally and displayed overlaid plots of some damped oscillations.

0 Kudos