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

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 III
15 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
Highlighted
15 Views

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

0 Kudos
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 Views
0 Kudos
Highlighted
15 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
Highlighted
New Contributor I
15 Views
I use Xeffort to draw pictures (graphs, schematics etc.) in a dialog.
0 Kudos
Highlighted
New Contributor I
15 Views

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

Brooks

0 Kudos
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
Valued Contributor I
15 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
Highlighted
15 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
Highlighted
Valued Contributor III
16 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
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
New Contributor I
15 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
Highlighted
Black Belt
15 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