Lining up %tt and %rf controls

I am using %tt with %rf and %rs to set up quite a complex parameter-setting window. Problem is that the controls don't line up properly. I thought at first it was the complexity of the window, and tried replacing %nl by %ff as suggested in KBase. No joy. Even a very simple window shows the problem - see below:

      subroutine testct ()
      character*12 label,help
      real*8 param
      integer e_mainhelp,parmca,parmgo
      external e_mainhelp,parmca,parmgo

      label = 'Parameter 1'
      help = 'This is help'
      param = 1.0

      jj=winio@('%ww%bg[white]%ca[parameter window]&')
      jj=winio@('%th&',1)
      jj=winio@('%?tt@@  &',label,help)
      jj=winio@('%8rf&',param)
      jj=winio@('%ff%nl%cn&')
      jj=winio@('%^tt[Help]&',e_mainhelp)
      jj=winio@('%^tt[Cancel]&',parmca)
      jj=winio@('%bc[yellow]%4^bt[Go]',parmgo)

      return
      end

The %tt control doesn't line up properly with the %rf control.

Not sure if the problem is mine or if it's something in Clearwin+

Would appreciate any suggestions

• Steve

Yes, it is a problem. I think if this is internal problem of CWP as opposed to WinAPI the alignment of all controls must me redefined

Sometimes using %ob[no_border] .... %cb will fix the alignment.

Another way is to use %dy to adjust the vertical displacement of one of the two controls.

Another way is to use %bt or %bb instead. A fully comprehensive %bb will be in the pending beta download.

Hi, Dan - Hope not -- but will try Paul's suggestions and see what happens! Many thanks, both, for such quick responses!

I used all these tricks and tell that they are a huge inconvenience so i mostly gave up. I have shown here some examples before which hopefully are fixed or in the work already (%su and %sd). Definitely CWP should be better readjusted (and then called CWPP 😃 ) . Here are few more examples

Also, i find default font size is too large for me, and when i decrease everything with %ts --> 0.8d0 (which i found experimentally when tried to compare CWP to other GUI builders) then GUI looks more professional. And worst of all is %eq - this needs more adjustments to look professional.

I tried %dy and it did the trick. Only one weird thing is that I set the displacement to 0.0 and that fixed it. Any other displacement and the controls are misaligned.

Next thing is to try out Dan's suggestion of reducing the text font size a little... beginning to get the hang of CW+ idiosyncrasies, but it's slow progress!

-Steve

I don't think that %tt is intended to line up with anything else but other %tt controls. The hint is in the expansion of %tt - 'textual toolbar'. If you use these buttons in their own toolbar, everything works. You will also find that %tt buttons are not infinitesmally scalable, they increment the x-size in quite large steps, unlike %bt which increments the x-size in smaller steps. Moreover the y-size of %tt is very different to that of %bt, and different again to %bb.

What is more, the whole shebang is predicated by the font size currently in use, as things are scaled according to a notional average character size block. You can see what this is by using the %gd grid control in your window. Not only does the positioning of controls depend on the font in use, you should note that the font changes between different versions of Windows, for example the system font in XP is different from Vista and 7 (who knows about 8), and this messes up careful positioning with %dy. If the target computer has large fonts enabled, this is also handled differently by dufferent versions of Windows.

If you want several %rf boxes to align vertically, then it is sometimes better to put the text to the right of them.

I had a little play with your code:

      winapp
      Program tryit
      real*8 parama, paramb 
      parama = 1.0d0
      paramb = 2.0d0 
      jj=winio@('%ww%bg[white]%ca[parameter window]&') 
      jj=winio@('%th&',1) 
      jj=winio@('%8rf Parameter #1%nl&',parama) 
      jj=winio@('%8rf Parameter #2&',paramb)
      jj=winio@('%ff%nl%cn&') 
      jj=winio@('%tt[Help]  &') 
      jj=winio@('%tt[Cancel]  &') 
      jj=winio@('%`tt[Execute]')
      write(*,*) jj, parama, paramb 
      end 
      resources
      1 24 default.manifest

You can, of course, program what you want, but the standard in windows is to highlight the default button, not colour it in. If the 'Go' button closes this window, you don't need a callback for it, just test the return code on exit (it's in JJ, and 0 means the close box was used). Of course, you can have callbacks on some buttons, and use the callback return value to close the window.

You might find it more helpful (no pun intended) to attach Help info to a different kind of button, say of the %ib type, positioned out of the row of 'Cancel' and 'Go' - say at top right of the screen - using the standard Help icon (sadly, not one of the @si icons), as every Windows user will know what it does.

Eddie

Hi, Eddie -- Thanks for the suggestions. That window is actually fairly similar to what I coded originally, but I wanted the tooltip help for each parameter. I first tried %bt buttons containing a '?' next to each parameter prompt, but these were too big and clunky, which is why I went for %tt instead. As for the horizontal positioning, that wasn't a problem - everything lined up just fine whether the label was left or right of the %rs / % rf input boxes. Rather than having a separate '?' button it seemed neater just to put the parameter labels in the %tt boxes, and because these are standard lengths the horizontal positioning worked fine. The only problem was the vertical misalignment.

I quite understand your comments about different system fonts messing up the %dy positioning. I guess one way out would be to specify a standard common font such as Arial, but even that can't be guaranteed always to be available.

By the way, what does your resource code do? It just threw an error message when I compiled it, so I commented it out and your example worked just fine.

As for the %ib suggestion, not sure this would improve the window layout, but it could be useful to get rid of the Help and Cancel buttons by using standard icons with the %si format.

Good point about the callback on the 'go' button - unnecessary!

thanks for the thoughts

-Steve

Hi Steve,

Silly me, I forgot you are still using that old FTN95. You can't define a manifest (whatever that is!) in a RESOURCES section in early FTN95 versions, it only works in a .RC file that you comple with the resource compiler SRC, and then link. For big codes it is no problem, for small ones the RESOURCES section is a help. The manifest includes all info on how the interface looks. Without it you revert very much to Windows 95 appearance. With it, you look like XP and later. Also, some of the controls don't just look different, they look better. I've never sussed what the 1 24 does, but the default.manifest uses - you guessed it probably - the default manifest!

I don't think I would use an icon for Cancel (I would for Help), but sometimes it is useful to have an icon on the buttons for Cancel and Accept. A lot of applications used to be compiled with a type of Pascal - you could always tell it was used by the cross on Cancel and the tick on Accept. For this you need a 16x16 icon on a %bb, and this gives you a thinner button than %bt.

As for tooltip help, I find the documentation rather difficult to follow, but using the option ms_style improves things hugely when using the manifest. Even so, help appears for %tb buttons even when greyed-out, but not for greyed-out %ib buttons.

In XP, the default font was Trebuchet, but a nice scalable font was MS Sans Serif. This looks old-fashioned now, and Segoe UI matches everything in Vista and 7. As it is just any old TrueType font, I suggest using it for all and getting any user stuck back in XP to load it themselves. As for putting your labelling on a button, I wouldn't recommend that, instead you can make text write only (you) i.e. read only (user), but update it dynamically. If the meaning of a parameter really is so obscure it needs nlots of explanation, then it is worth having a permanent box, the contents of which vary when the parameter's input box gains focus.

The advice not to have callbacks on buttons that close the window reduces the number of functions in a program, and you usually have to test for the WINIO@ callback number being 0 anyway, as that occurs if the user closes the window with the top-right close box.

Having %mi gives the user the ability to access MAXIMISE from the system menu, so unless you explicitly disable it, you need something expandible in the window (say a %gr or %cw with a %pv pivot) to fill the space if the window is maximised, and that tends to keep buttons aligned.

eddie

Hi Eddie - I've now bougfht the FTN95 v6.35. Your sample works beautifully, and I've put the default.manifest line into my mainline - all the buttons now do indeed look much nicer on the XP development machine. Haven't yet copied across to this machine (Win7).

It's a complex application as I said. One mainline that calls about 100 different 'main' subroutines each of which needs up to 5 files, up to 20 field definitions,. and similar number of parameter settings. Some are standard across the system, some not - and some need 3 or 4 lines of explanation. I get all this 'help' information from a set of fixed-format text files, one for each main subroutine. Sounds clunky and it could be, but the tooltip help makes it all look much smoother. This is why I'm using the %tt buttons for the labels. Would be nice to have tooltips available if you hover over other sorts of controls e.g. %ws but %tt will do in the meantime - I just have to ensure it does nothing when clicked, so using the 'CONTINUE' callback.

Will experiment with different fonts later, but priority now is to get the 100 main subroutines working properly :roll:

Quoted from silicondale Sounds clunky and it could be, but the tooltip help makes it all look much smoother. This is why I'm using the %tt buttons for the labels. Would be nice to have tooltips available if you hover over other sorts of controls e.g. %ws but %tt will do in the meantime

You can easily add tooltips for all sorts of controls. You just need a few simple WinAPI calls to do it.

Actually, I just wrote a few simple ready to use routines for you and put those inside a DLL... I modified the Eddie's sample and added the ToolTip support.

Available here. Have fun!

Wow, jalih! that looks just brilliant. many thanks indeed. That will indeed allow me to tidy up the files/fields/parameters page. The sooner I've got this legacy software (1970s-80s) sorted out, the sooner I can start adding some new stuff that I have lined up, and they can share the same user interface, so these tooltips will be important!

• Steve

Jalih

I have had a quick look at your impressive sample. Can you give me some clues on how to implement the icons in the tooltips/infotips? At first sight it looks like they have to be 'user' drawn.

I don't know if the feature can be easily imported into ClearWin+ but it is worth a thought.

Paul

Jalih,

That is truly impressive. I hope that Paul can implement some of it in the official Clearwin dll - the complexities of multilanguage programming put some of this outside the capabilities of some of us oldies.

Your use of the standard Help icon has given me another thought. For some time I have hankered after the ability to put little icons against some of my menu items. Clearwin does have (as standard) the ability to put a tick box against a menu item. It didn't seem to matter so much prior to Vista, but now the standard menu format clearly delineates space for an icon and this makes menus with no icons anywhere look rather bare.

Eddie

Quoted from PaulLaidler

Can you give me some clues on how to implement the icons in the tooltips/infotips? At first sight it looks like they have to be 'user' drawn.

I will put my DLL sources available later tonight, when I get home. It's only a few lines of MiniBASIC code and should translate directly into C.

Setting the tooltip icon is really simple. You just specify the icon when you set the title for the tooltip.

Something like:

 SendMessageA(hwnd,TTM_SETTITLE,TTI_INFO,&title_string)

where:

• hwnd is the window handle for the tooltip control
• TTM_SETTITLE tells we are setting the title
• TTI_INFO use the info icon (some other possibilities: TTI_WARNING, TTI_ERROR)
• &title_string is the addres for the tittle string

How about adding ClearWin+ format code to provide tooltip for the last created control? Different kinds of tooltips could be supported like the balloon tooltip for an example.

I post my sources later tonight. Let me know, if you need some help...

I made some small modifications into my previous sample and got rid of GetInstance() function. Updated package available here.

MiniBasic source for the tooltip.dll:

##ifndef WIN32
##define WIN32
##endif
 
##ifdef WIN32
##define WIN32_LEAN_AND_MEAN
##endif
 
##include 'winsdk\\windef.mbi'
##include 'winsdk\\winuser.mbi'
##include 'winsdk\\winbase.mbi'
##include 'winsdk\\Commctrl.mbi'

##NOCONSOLE
##MAKEDLL


export ToolTip
func ToolTip(HWND hwnd, string title, string tiptext)
	TOOLINFO tif
	HINSTANCE g_hInst
	HWND chwnd

	g_hInst = GetWindowLongA(hwnd,GWL_HINSTANCE)

	tif.cbSize = len(tif)
	tif.uFlags = TTF_SUBCLASS|TTF_TRANSPARENT  
	tif.hWnd = hwnd
	tif.uId = 99
	tif.hinst = g_hInst
	tif.lpszText = tiptext

	chwnd = CreateWindowEx(WS_EX_TOPMOST,'tooltips_class32',NULL,_ 
					WS_POPUP |TTS_NOPREFIX|TTS_ALWAYSTIP,_ 
					CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,_ 
					hwnd,NULL,g_hInst,NULL)

	SetWindowPos(chwnd,HWND_TOPMOST,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE)

	GetClientRect(hwnd,tif._rect)
	SendMessageA(chwnd,TTM_SETTIPBKCOLOR,RGB(255,255,128),0)
	SendMessageA(chwnd,TTM_SETTIPTEXTCOLOR,RGB(0,0,255),0)
	SendMessageA(chwnd,TTM_SETTITLE,TTI_INFO,&title)
	SendMessageA(chwnd,TTM_ADDTOOL,0,&tif)
endf

Thanks. That's very helpful.

Another small update...

Added support for balloon tooltips and user specified icon.

Updated files available here

MiniBASIC source for the updated DLL:

##ifndef WIN32
##define WIN32
##endif
 
##ifdef WIN32
##define WIN32_LEAN_AND_MEAN
##endif
 
##include 'winsdk\\windef.mbi'
##include 'winsdk\\winuser.mbi'
##include 'winsdk\\winbase.mbi'
##include 'winsdk\\Commctrl.mbi'

##NOCONSOLE
##MAKEDLL

const NORMAL = 0
const BALLOON = 1


export ToolTip
func ToolTip(HWND hwnd, uint tiptype, HICON icon, string title, string tiptext)
	TOOLINFO tif
	HINSTANCE g_hInst
	HWND chwnd
	uint tipstyle

	g_hInst = GetWindowLongA(hwnd,GWL_HINSTANCE)

	tif.cbSize = len(tif)
	tif.uFlags = TTF_SUBCLASS|TTF_TRANSPARENT  
	tif.hWnd = hwnd
	tif.uId = 99
	tif.hinst = g_hInst
	tif.lpszText = tiptext

	tipstyle = WS_POPUP|TTS_NOPREFIX|TTS_ALWAYSTIP
	if tiptype = BALLOON then tipstyle |= TTS_BALLOON

	chwnd = CreateWindowEx(WS_EX_TOPMOST,'tooltips_class32',NULL,tipstyle,_ 
					CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,_ 
					hwnd,NULL,g_hInst,NULL)

	SetWindowPos(chwnd,HWND_TOPMOST,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE)

	GetClientRect(hwnd,tif._rect)
	SendMessageA(chwnd,TTM_SETTIPBKCOLOR,RGB(255,255,128),0)
	SendMessageA(chwnd,TTM_SETTIPTEXTCOLOR,RGB(0,0,255),0)
	SendMessageA(chwnd,TTM_SETTITLE,icon,&title)
	SendMessageA(chwnd,TTM_ADDTOOL,0,&tif)
endf

Jalih -

I have to add that I'm seriously impressed!

• Steve

I have added [balloon] to the options for %th (in fact it was already there but commented out).

Also the help text will be able to take the form:

'|*Title|Info'

Starts with a pipe symbol,

then * or ! or # (as in %si) for the info icon etc.

then the title

then another pipe

then the information.