Text Window Program and Scrolling

[John_N_2]

Dear Steve:

I have now been able to get the TEXTWIN program running, but I cannot get it to scroll automatically,

[cpp]	!   re-entry point for multiple hex lines
			!	scroll up previous contents
			iret = GetClientRect (hwnd, crect)
		1	iret = ScrollWindow (hwnd, 0, -cychar, crect, crect)


I also am having trouble finding out about the ingter color codes and how to make rgb to int in IVF - please help.		[/cpp]

[cpp]IF (nprint > 0) THEN
					IF (mode /= regular) THEN
			!			iret = MSFWIN$SetBkColor   (hdc, bk_color)
						iret = MSFWIN$SetTextColor (hdc, 200)
						mode = regular
					END IF
					iret = TextOut (hdc, xpos, ypos, printstring, nprint)
				END IF[/cpp]

It has been a long learning experience and worth it.

I think there is still a header file or something I am missing from the original as I had to set some values.

Thanks

My new IVF code has still not arrived from Programmers Paradise --------

JMN

[Paul_Curtis]

First, Steve Lionel has absolutely nothing to do with this program sample (other than providing the IVF product and this wonderful support forum), so please do not blame him, nor burden him with support questions on code he did not create.

The textwindow proc function scrolls the window contents upwards by one text line (ie, its font height in pixels) each time the proc receives a WM_PAINT, whereupon the next text output line is written at the bottom of the window. The idea is that the calling context will request text output one line at a time, and will issue a separate call for each line of output.

Provision is made for internal iteration within the proc to deal with special cases such as output which needs to be rendered in hex and which may map to multiple output lines; perhaps this was too complex and should be omitted from the example to make things simpler (in the original context, textwindow output is used to trace driver-level command interaction with external devices, where the command/response syntax is often non-printable). In the original, each output line is preceded by a timestamp as well; this approach provides infinite flexibility.

RGB colors in Windows are expressed as three 8-bit (ie, 0-255) values representing the red, green and blue intensity levels, packed into the 3 LSBs of an I*4 which can then be passed to and from the Win32 API routines. Please let me know what other constants or features require further explanation.

[cpp]SUBROUTINE create_RGB_colors
	IMPLICIT NONE
	
	white		= Make_RGB (255,255,255)
	ltgray		= Make_RGB (220,220,220)
	gray		= Make_RGB (192,192,192)
	
	palegreen   = Make_RGB (148,242,142)    
	green		= Make_RGB (  0,108,  0)
	medgreen	= Make_RGB (  0,155,  0)
	olivegrn	= Make_RGB (124,124, 63)
	ltgreen		= Make_RGB ( 15,179,134)

	britepink   = Make_RGB (243, 67,194)
	pink		= Make_RGB (252,150,232)    
	sand		= Make_RGB (255,200,140)
	red			= Make_RGB (198,  0,  0)
	darkred		= Make_RGB (155,  0,  0)
	britered	= Make_RGB (255,  0,  0)

	orange		= Make_RGB (255,112, 43)
	yellow		= Make_RGB (255,255, 40)
	paleyellow	= Make_RGB (252,255,168)

	blue		= Make_RGB (  0,  0,217)
	paleblue	= Make_RGB (176,222,222)
	ltblue		= Make_RGB (155,255,255)
	blugray 	= Make_RGB ( 44, 69,107)	
	ltblue2		= Make_RGB (  0,174,174)
	purple		= Make_RGB (217, 43,190)
	fuschia 	= Make_RGB (255,  0,128)
	darkblue	= Make_RGB (  0,  0,160)

	default_background_color = Make_RGB (166,198,210)
				
END SUBROUTINE create_RGB_colors


!   wrapper function to convert supplied INTEGER*4 color values
!   to BYTE format required by Win32 API function RGB
INTEGER FUNCTION Make_RGB (red, grn, blu)
    IMPLICIT NONE
    INTEGER, INTENT(IN)     :: red, grn, blu
    Make_RGB = RGB (INT1(red), INT1(grn), INT1(blu))
END FUNCTION Make_RGB



[/cpp]

[John_N_2]

Dear Paul:

Thank you very much for your response. I should have directed the query to you and so I apologize for my error.

I must say that I have spent several enjoyable weeks buried in your code to understand what it is doing, and really to teach myself the basics of a windows program. Petzold helped a lot after I purchased the book.

I have created RGB colors elsewhere, I just could not find the reference to a function I could get to work. Thanks for the functions, I can now fix my code.

I did however have one problem I can not solve, when the program calls the scroll window api routine, it does not scroll. This is why I had included the entire project in a zip file with my last post. I was hoping that someone who knows more about these functions than I could take a look at it and tell me what I have done wrong with the scroll function.

The real trouble I am having is not dealing with the coding, it is in finding a decent listing of the API functions that IVF can call. I find the integrated Fortran help files within the MS Development Studio difficult to find what you want and often short on examples.

I say this realizing we are very lucky to have Intel supporting the Fortran program, I realize how much this must cost and probably they do not get a great return on it, and Steve is a great resource and we are even more lucky to have him in one place for such a long time.

This version of Fortran is significantly better than all the others I have used and clearly it is due to the Intel coding team, I have no where near the hassles I had in the 1990's trying to get programs to run.

I need to spend some time hunting out the documentation, but if there is a PDF of the main Fortran callable API routines if someone could point me at it that would be great.

Finally for those of you that like to play with a sweet little program go try the Microsoft Small Basic, great for kids, although its simplicity hides its power.

JMN

[Steven_L_Intel1]

Fortran can call just about any Win32 API routine. The exceptions are those provided as C++ classes only. If it can be called from C, it can be called from Fortran.

Rather than a "list", I think you want a book on Win32 programming in general. Even though they're usually aimed at C programmers, the C code can generally be directly reinterpreted as Fortran. The API calls themselves are usually straightforward - reading the declarations in the Fortran sources to the Win32 modules provided by IVF can be helpful in getting types right.

[Paul_Curtis]

Quoting - MacNeacail

... when the program calls the scroll window api routine, it does not scroll. This is why I had included the entire project in a zip file with my last post. I was hoping that someone who knows more about these functions than I could take a look at it and tell me what I have done wrong with the scroll function.

The real trouble I am having is not dealing with the coding, it is in finding a decent listing of the API functions that IVF can call. I find the integrated Fortran help files within the MS Development Studio difficult to find what you want and often short on examples.

ScrollWindow() and other API functions are documented both within VisualStudio help (the MS part), and also on the web, http://msdn.microsoft.com/en-us/library/bb787591(VS.85).aspx. If the function is not working, running the return value through GetLastError may tell why. I haven't had a chance to inspect your code file, but the original works really well, and when tracking a fast communications stream will pound text through the window at hundreds of lines per second.

Almost all of the Win32 API functions now have F90 interfaces supplied with IVF, and searching the standard fortran include path (instead of your project files) will point to the interface code for any particular function, which is very useful for inspecting the types of arguments, as to whether the function requires a particular data type directly or its LOC(). All the Win32 API functions are accessible from Fortran, but you may have to write your own interface if IVF hasn't supplied one.

[John_N_2]

Dear Steve and Paul:

I replied strictly in the order you replied to the last post.

I got Petzold, which is an excellent book, but I had not thought to use the include files.

I have downloaded the SDK for Windows and will have a look at that.

Thanks

JMN

[Paul_Curtis · Accepted solution]

After a very quick look at your code, let me suggest that you need to explicitly invoke SAVE as a global attribute in all your proc functions, as any object without that attribute will likely vaporize between calls. SAVE used to be the default behavior of CVF and many (all?) earlier Fortrans, but is not the default for IVF.

This is particularly important with Windows procs, since each passage through the CASE tree is a separate call so that, for example, the crect and other quantities initialized in WM_INITDIALOG need to be retained for subsequent use by ScrollWindow() in the WM_PAINT code block.

[John_N_2]

Quoting - Paul Curtis

After a very quick look at your code, let me suggest that you need to explicitly invoke SAVE as a global attribute in all your proc functions, as any object without that attribute will likely vaporize between calls. SAVE used to be the default behavior of CVF and many (all?) earlier Fortrans, but is not the default for IVF.

This is particularly important with Windows procs, since each passage through the CASE tree is a separate call so that, for example, the crect and other quantities initialized in WM_INITDIALOG need to be retained for subsequent use by ScrollWindow() in the WM_PAINT code block.

Dear Paul:

I was just starting to think about static rather than local variables. It takes a while to shift from one language to another. I had been following the flow of the program with the watch screens and when I read your stuff that nagging feeling in the back of my head turned into a ---------- where did some of the variables go.

Thanks heaps,

It is good code, I might just be able to squeak through with my limited windows knowledge.

JMN

[John_N_2]

Dear Paul:

I spent an enjoyable night buried in the code and VS2008 watching the variables change and watching the window form.

The program is having problems with the busy variable. The program skips over the first write routines if I have a second trace routine stacked up behind the first one.

Weekend project, solve the problem of busy.

The saves worked a treat, thanks

JMN

[Paul_Curtis]

Quoting - MacNeacail

The program is having problems with the busy variable. The program skips over the first write routines if I have a second trace routine stacked up behind the first one.

The busy flag, which must be SAVEd and of modular scope, signals that a WM_PAINT is in progress, and blocks SendMessage for subsequent output until the current WM_PAINT completes. An observation of occasional messages printed out of order led to the creation of the busy flag, but since its addition I have never seen any problem with skipped messages or message order. The busy timeout is open-loop (ie, will block forever unless cleared by WM_PAINT) and probably should be re-coded with an escape hatch so it can't hang, but the WM_PAINT operation is so fast that pileup has never been observed. I will note that this is used in an extensively multithreaded context, but only one thread at a time can be enabled to produce messages to the text window.

In case this thread may have jumped the shark or become of declining interest to the wider forum community, I will be glad to continue this discussion privately; my email is paul kiltel com.

[John_N_2]

Quoting - Paul Curtis

The busy flag, which must be SAVEd and of modular scope, signals that a WM_PAINT is in progress, and blocks SendMessage for subsequent output until the current WM_PAINT completes. An observation of occasional messages printed out of order led to the creation of the busy flag, but since its addition I have never seen any problem with skipped messages or message order. The busy timeout is open-loop (ie, will block forever unless cleared by WM_PAINT) and probably should be re-coded with an escape hatch so it can't hang, but the WM_PAINT operation is so fast that pileup has never been observed. I will note that this is used in an extensively multithreaded context, but only one thread at a time can be enabled to produce messages to the text window.

In case this thread may have jumped the shark or become of declining interest to the wider forum community, I will be glad to continue this discussion privately; my email is paul kiltel com.

Dear Paul

Thanks, I will try myself on busy, I am determined not to let Windows beat me to much.

When I run out of effort then I will email

JMN