Re: QuickWin/DFLOGM/Win32

marshallc · ‎04-26-2006

Hi,

I'm trying to get an understanding of the various "flavors" (for lack of a better word) of Visual Fortran. What is the difference between QuickWin, DFLOGM and Win32? I think QuickWin is a basic form of Fortran, and DFLOGM is some sort of wrapper/interface to Win32. Can you use QuickWin in DFLOGM and vice versa?

Would the following be considered an example of DFLOGM or Win32:

Code:

    select case ( mesg )

      case (WM_CREATE)
        ihWndstatus = CreateStatusWindow (IOR(WS_CHILD, &
          WS_VISIBLE), " "C, hWnd, IDC_StatusBar)
        
        iParts = 3
        bRegValuesEmpty = TRUE
        MainWndProc = 0

      return
      
      case (WM_SIZE)
       
        cxClient = loword(lParam)
       cyClient = hiword(lParam) 
      
        iret = GetWindowRect(ihWndStatus,RectStatus)
      iSBheight = Abs(RectStatus%bottom-RectStatus%top)
      iret = GetClientRect(hWnd,rcClient)
      cxWidth = rcClient%right/iParts
      iStep = cxWidth

I have been reading the posts in the forum and have seen mention of IFLOGM/DFLOGM. I'm also reading the book "Compaq Visual Fortran" which only seems to present information on QuickWin and Win32... no mention of IFLOGM/DFLOGM in the index. I'm guessing this is something that is particular to the Intel version of Visual Fortran and not the Compaq version. The help files for IVF present some information about DFLOGM/IFLOGM, but it's a little hazy on what I can or cannot do with the "flavors".

Chad

Jugoslav_Dujic · ‎04-26-2006

It's quite natural that you're confused, especially if you have read CVF documents on the topic. OK, I'll try to present the accurate information:

All three are present in both CVF and IVF (IVF ones have prefix "I" (IFLIB, IFLOGM, IFWIN) but ones with prefix "D" still work).

DFWIN is just an interface to (almost) full set of Windows APIs, implemented in Windows system dlls. Windows API is (mostly) language-independent and you can do with it (almost) anything you can do with Windows.

QuickWin (most routines implemented in USE DFLIB, but there's some more stuff apart from it) is a library for GUI programming, written by Microsoft in mid-80s, inherited by Digital, Compaq and Intel successors. It lets you do some basic GUIs. It's written using Windows APIs (but you might not see it as user). It's a "framework" type of library, in the sense that you can use QuickWin routines only in a "QuickWin" type of application (i.e. you can't call them from e.g. a dll).

Now, DFLOGM/IFLOGM is another library for GUI programming, particularly dialogs. It's also written using Windows APIs, but it's a wrapper library, not a framework. That means you can use DFLOGM functions from any type of application (GUI, console, dll, QuickWin)

The bottom line is, DFLOGM and QuickWin are independent and unrelated libraries, both built on top of Windows APIs (which are kinda difficult to use). CVF docs confused the issue by sticking them together in the same "Using QuickWin" chapter, although DFLOGM is totally independent of QW. Also, since both are built on top of Windows API, you can call Windows API functions for "their" objects. For example, API calls MoveWindow(GETHWNDQQ(QWIN$FRAMEWINDOW),...) and MoveWindow(Dlg%Hwnd,...) will work as expected on QuickWin frame window and TYPE(Dialog) window. The reverse is not true -- if you created a window using hWnd=CreateWindow(...) or hWnd=DialogBox(...), you can't call SetWindowConfig or DlgGet for it.

Does it make things clearer?

marshallc · ‎04-26-2006

Yes, it does. Thanks!

I've worked with Visual Basic and C++, and they don't seem to have the different variances that Visual Fortran has. When I start a Visual Fortran application, it asks if I want a QuickWin or a Win32 application. Which do you select? The problem is that I see examples in the book and in the help that suggests that there might be some sort of crossing between the two, but I'm not sure how to perform something in one versus the other and vice versa.

For example, I ran into a problem with QuickWin that I wasn't able to modify the status bar. I found an example in the book that was able to modify the status bar, but it was in a Win32 application. With the Win32 application, I'm running into a problem where I need to perform an action if a radio button is selected, but it seems like it is done in DFLOGM which seems to be different than how I have everything coded which is Win32. That's the example that I pasted at the top of this thread.

I'm getting confused on two things... How should my application be built, Win32 or QuickWin, that would give me the flexibility that I need?... and... How do I do what I need to do in that particular option? It would be great if there was only one path to take for programming in Visual Fortran... not a QuickWin version or a Win32 version... just a simple this is Visual Fortran. With other programming languages you have DLLs, COM objects, etc... but those are add-ons to your main code... not different ways of coding the main code like there is with Visual Fortran. For me coming from VB and C++, this is confusing.

Chad

Jugoslav_Dujic · ‎04-26-2006

But in C++ you also have MFC, WTL, ATL, WxWindows, .NET... with a lot of overlap... Things aren't so simple... Browse through "New project"/C++ and you'll see so many available project types that you'll get dizzy (I do).

Well, Win32 gives you all the flexibility you need... and then some. It's a bit difficult to use, though. But I can't really answer the question which one is more suitable for you, as I don't know your needs. QuickWin is simple but also limited and often sluggish. DFLOGM is confined to dialogs, but you can use it freely in a Win32 application (and QuickWin, of course). For example, VF Application Wizard will give you a DFLOGM-based code if you select "Win32 application/Dialog-based".

For example, In DFLOGM, you will get the radio button status using DlgGet(IDC_RADIO, bState). In Win32, you can query SendDlgItemMessage(hDlg, IDC_RADIO, BM_GETCHECK, ...).

I understand your confusion, but, sorry I can't be more specific at the moment; the situation is as follows: if you decide to learn "pure" Win32 first, you will get a broad and deep knowledge, but your learning curve will be lean, and you won't get results (working applications) quickly. In QuickWin or DFLOGM, you get results quickly, but your flexibility is limited. For what it's worth, I started with QW/DFLOGM and gradually added Win32 code (and knowledge) to it. (applying APIs on GETHWNDQQ, then subclassing, then...).

You can check out my home page www.xeffort.com for yet another solution (which I deem the right compromise between complexity and power, but of course I'm biased). Yes, it will give you a "Fortran Xeffort Application" in New/Project :-). In any case, you can take a look at "Miscellaneous samples" and Xeffort samples. Maybe it would make things somewhat clearer...

marshallc · ‎04-26-2006

Thanks, Jugoslav, for letting me pick your brain on this.

Actually, I haven't seen the new C++ (the one in Visual Studio.NET). I programmed in it before it was packaged withMicrosoft's programming suite. Things have changed, but I guess for the better to allow for flexibility. For someone that has been away from it for a while, it's a tailspin to get back up to speed on the changes. The biggest... object oriented programming.

In your example with the radio button, let me see if I understand it correctly. With a Win32 application, I could either use SendDlgItemMessage... which is the "pure" Win32 way of querying a radio button... or I could use DlgGet which is the DFLOGM version, and DFLOGM is the wrapper or interface that IVF uses to interface with Win32 APIs... right?

I think in some respects QuickWin would have beenthe right path to take in getting this project done, but I had a couple hurdles that made me select Win32. To name a couple, I need to be able to modify the status bar and have date/calendar controls. The analyst needs to be able to have the coordinates showing on the status bar while moving the mouse. I found an example of this, but it is written for Win32 applications. I could not figure out a way to port this code to a QuickWin application. With the Win32 application, the case statements for all the different events are throwing me for a loop since I'm not used to coding with these as well as the passing of windows and such between functions. When I last worked on code, the only things being passed between functions were arrays and variables. I guess I'm a bit out dated when it comes to coding :)

Chad

Steven_L_Intel1 · ‎04-26-2006

The way I like to position QuickWin is that it's for the traditional Fortran programmer who wants to give their existing application a "Windows look and feel" without extensive rewriting. At a minimum, all it takes is selecting the QuickWin project type, and a plain old "Hello World" type Fortran program now has a window with scrolling, cut, paste, menu bars, etc. You can then incrementally add features such as menus or graphics in a Fortran-friendly way. QuickWin is also the ONLY way to take ordinary Fortran I/O and have it directed to a window.

QuickWin is not meant as the ultimate solution for everyone and it has its limitations. But all the other choices require some re-thinking of your application if you want a full Windows UI. (As Jugoslav says, adding dialog boxes is pretty simple for any application type, even console.)

anthonyrichards · ‎04-26-2006

The piece of code you postedlooks likeclassic win32 stuff, an excerpt from a main window procedure that handles the 'message loop' that is required when operating. Messages such as WM_COMMAND, WM_PAINT, WM_SIZE etc.

Quickwin sets up its own window procedure and runs its own message loop to control all the windows that you can create in Quickwin, from a seperate thread. In Quickwin, all you do is run a program in its own thread to create and modify windows and assign 'call back' routines to each menu item that you want to control. Your main program then goes to sleep ( you will find a 'do nothing forever' loop inside the Quickwin examples, which is OK since the main work is being done in a seperate thread you have no direct control over).These call backs are then called from the Quickwin window procedure.

The Quickwin status bar is a single window whose text can be changed. (I will post the interface to the routine required tomorrow). If you want a more complicated status bar, then you will have to go the WIN32 way I think.

marshallc · ‎04-27-2006

To help me visualize how you can take something in Win32 and use it in a QuickWin app, could someone show me a piece of Win32 code... and then take that code and "convert" it to QuickWin code?

wen · ‎06-14-2006

This is not a reply. I am writing a new question related to the current topic.

What about a third party package such as Winteracter, in comparison to QuickWin/DFLOGM/Win32?

I am working on converting a set of old Fortran code to the one with a lot of dialog I/O and graphic output. When I used Lahey Fortran before I moved to IVF, I found Winteracter easy to use, probably because the package came with many sets of sample code for practical application.

After I switch to IVF, I started using QuickWin. I am still struggling to figure out which basic routines I need to plot a simple x-y curve. I could not find sample programs except limited ones in xeffort.com. I guess I could make it soon but I am not sure whether there is any easy way to plot scattering x-y point with a special symbol.

Would anyone suggest me using something like Winteracter for easier work?

Wen

Steven_L_Intel1 · ‎06-14-2006

You can use Winteracter if you're comfortable with it. Building a "Win32" application is much more complex and usually requires changing the structure of the program. DFLOGM is a separate thing and can be used with any of the project types.

Look at the Scigraph sample in the samples I posted at the top of this forum. It is QuickWin.

wen · ‎06-15-2006

Steve,
Thank you. All those sample routines are useful to me. I saw them when I join the forum and then forgot about them.
Wen