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

dialog graphics

Brooks_Van_Horn
New Contributor I
1,026 Views

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
1 Solution
andrew_4619
Honored Contributor II
1,008 Views

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
Steven_L_Intel1
Employee
926 Views

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

0 Kudos
Brooks_Van_Horn
New Contributor I
926 Views

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
Brooks_Van_Horn
New Contributor I
926 Views

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
Brooks_Van_Horn
New Contributor I
926 Views

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
Brooks_Van_Horn
New Contributor I
926 Views
0 Kudos
Steven_L_Intel1
Employee
926 Views

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.

0 Kudos
Neels
New Contributor II
926 Views
I use Xeffort to draw pictures (graphs, schematics etc.) in a dialog.
0 Kudos
Brooks_Van_Horn
New Contributor I
926 Views

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

Brooks

0 Kudos
Brooks_Van_Horn
New Contributor I
926 Views

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
Neels
New Contributor II
926 Views

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
dboggs
New Contributor I
926 Views

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
Paul_Curtis
Valued Contributor I
926 Views

"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
Steven_L_Intel1
Employee
926 Views

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. 

0 Kudos
andrew_4619
Honored Contributor II
1,009 Views

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.

 

0 Kudos
dboggs
New Contributor I
926 Views

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
Neels
New Contributor II
926 Views

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
Anthony_Richards
New Contributor I
926 Views

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
Brooks_Van_Horn
New Contributor I
926 Views

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
mecej4
Honored Contributor III
926 Views

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
Brooks_Van_Horn
New Contributor I
810 Views

I made a VS project with the 4 .f90 files and the .rc and .ico files. I changed the call to change the color by creating a new pen with color. All compiles well but the linker can't find _MAIN__. I looked thru the code and nothing but WinMain is there. So make files won't help me.

Brooks

0 Kudos
Reply