- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compiler has nothing to do with this. Can you point to a description of the C example you saw?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks boyh. I think I'll evaluate the Xeffort code.
Brooks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page