Controlbox

[sdocker]

Changing the ControlBox properties does not work at runtime as it does during development.

Am I missing something.

Thanks,
Sam

 

[sdocker]

Some more info:

At runtime the ControlBox in top left corner reflect the properties setting.

It is the buttons on top right that are active even when ControlBox was disabled.

Sam

 

[Mike Lewis]

Sam,

What you are describing is not normal behaviour.

If you set <form>.ControlBox to .F., then both the control box and all the buttons at the right-end end of the title bar are invisible.

If you set it .T., then the control box and the right-hand buttons are visible. The minimise and/or maximise button might be greyed out, depending on the setting of the MinButton and MaxButton properties. If both those properties are .F., then only the Close button will be visible.

The above applies both at run time and design time. The only difference is that, at design time, the Close button is always greyed out (regardless of the Closable property).

Does that help at all?

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sdocker]

Hi Mike,

Perhaps I should have mentioned that I change the controlbox property in the gotfocus and lostfocus methods.

The property setting at design time is obeyed. it is the chabges in the code that only work in development, and not in the runtime.

Sam

 

[Mike Lewis]

Sam,

Events like GotFocus and LostFocus don't fire at design time.

But, when you say "at design time", perhaps you mean "when running in the development environment"? That's not the same thing.

I've never tried setting ControlBox from within an event like GotFocus. I don't know why you would want to do that. But I can't see any reason for it not to work. I'll try it myself when I can grab a moment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sdocker]

Mike,

Thank you.

I do mean "in the development environment". I didn't know they were different.

The reason for doing it is I have a small data entry form on the main form. If data is entered on the small data entry form, I don't want to allow the user to close the application without first closing the data entry form which will automatically save any changes.

Sam

 

[mjcmkrsr]

Hi sdocker

What about Form.Titlebar = 0 or Form.Show(1), which makes it modal.

You may perhaps have to Form.Refresh after Form.Gotfocus() and Form.LostFocus()

hth

MarK

 

[Mike Lewis]

Sam,

The usual way to solve that problem is to write code in the form's QueryUnload method. That method fires whenever the user does something that will result in the form being closed. The "something" includes closing the application - and even closing Windows.

The code in the QueryUnload should ideally check for unsaved edits. If there are any unsaved edits, it should then prompt the user to save them.

A simpler approach would to make the form modal, but that is not completely reliable. In particular, if you have a menu command that closes the application, the user will still be able to select that command, even though the form is modal (unless you grey it out with a SKIP FOR clause).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sdocker]

Thanks Mark,

Hiding the titlebar doesn't work in the runtime.

Sam

 

[mjcmkrsr]

Hi Sam,

Sure? Please see code below

hth

MK

PUBLIC go_Form
go_Form = CreateObject ("frmForm")
go_Form.Visible = .T.
go_Form.Show
READ Events
CLOSE ALL
CLEAR ALL


DEFINE CLASS frmForm As Form
  Width = 420
  Height = 360
  AutoCenter = .T.
  
ADD OBJECT cmdToggle as commandbutton WITH ;
	Top = 24, ;
	Left = 24, ;
	Width = 120, ;
	Height = 42, ;
	Caption = "Toggle Titlebar"
	
	PROCEDURE cmdToggle.Click()
		go_Form.TitleBar = ABS(go_Form.TitleBar - 1)
	
	ENDPROC

ADD OBJECT cmdExit as commandbutton WITH ;
	Top = 102, ;
	Left = 24, ;
	Width = 120, ;
	Height = 42, ;
	Caption = "Exit"
	
	PROCEDURE cmdExit.Click()
		go_Form.Release
		CLEAR EVENTS
		
	
	ENDPROC
	
ENDDEFINE

 

[mjcmkrsr]

...
Test with two forms

PUBLIC go_ModalForm, go_Form

go_Form = CreateObject("frmForm")
go_ModalForm = CreateObject("frmForm")

WITH go_Form
	.Show()
	.Move(12,12)
ENDWITH 

go_ModalForm.Show(1)
*!*	READ Events
CLOSE ALL
CLEAR ALL


DEFINE CLASS frmForm As Form
  Width = 420
  Height = 360
  MinWidth = This.Width
  MinHeight = This.Height
  AutoCenter = .T.
  
ADD OBJECT cmdToggle as commandbutton WITH ;
	Top = 24, ;
	Left = 24, ;
	Width = 120, ;
	Height = 42, ;
	Caption = "Toggle Titlebar"
	
	PROCEDURE cmdToggle.Click()
		WITH go_ModalForm
			.TitleBar = ABS(.TitleBar - 1)
		ENDWITH 
	
	ENDPROC

ADD OBJECT cmdExit as commandbutton WITH ;
	Top = 102, ;
	Left = 24, ;
	Width = 120, ;
	Height = 42, ;
	Caption = "Exit"
	
	PROCEDURE cmdExit.Click()
		
		RELEASE go_Form, go_ModalForm
				
		CLEAR EVENTS

	ENDPROC
	
ENDDEFINE

 

[sdocker]

Thanks guys,

All the ideas were helpful.

I ended up making greying out the "Exit" menu item, when required. A reasonable workaround.

I'll add this to my list of things about VFP that I still have to figure out why it happens.

Sam

 

[Mike Lewis]

I ended up making greying out the "Exit" menu item, when required. A reasonable workaround.

Sam, that's a reasonable short-term solution.

But, at some point, I think you should consider what I wrote earlier about using QueryUnload. The point is that, if the user tries to close the app while there are unsaved edits, he should be given a choice of whether to save the edits, to abandon them, or to cancel the closing of the app. That's what most applications do, and that's what users expect.

I can see this isn't a priority just now, but you should think about adding that behaviour in due course. (And, of course, if you have a base form class, you can put it in at the class level so it will work consistently throughout the app.)

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads