Toolbars

[sdocker]

Hi,

Is it possible to adjust the height of a toolbar. I can't seem to accomplish it and am wondering why it is larger than the VFP ToolBars in the IDE.

Also, is it possible to keep the menu active when opening a FormSet. I understand I would have to control it with SET SKIP ......

Thanks,
Sam

 

[Mike Lewis]

In general, you can't directly control either the height or the width of a toolbar. When the toolbar is docked, it automatically adjusts itself. If it is docked horizontally (top or bottom of the screen), it adjusts itself to the width of the main Foxpro window, and to the height of the contained controls. And vice versa if docked vertically.

However, there is a useful trick which will overcome this limitation: Insert a single container in the toolbar. Then insert all the other controls (buttons, etc) in the container. You can then adjust the height or width of the container programmatically, and the toolbar will resize itself accordingly.

I do this in most of my applications. In fact, I have a toolbar that contains a container that in turn contains a page frame. It works surprisingly well.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

About your second question: Whether the menu is active or not depends on the nature of the form, modal forms cause modal states, meaning you can't do anything in parallel, also not use the menu.

Bye, Olaf.

 

[sdocker]

Mike,
I had read your comment in a previous thread and tried it, but could not get the control into the container. I'll give it another shot and get back.

Olaf,
I have a modeless form set. It has 2 modeless forms showing in the Top level Form. The menu is disabled if either of the forms are active. I have to click on the top level form to enable the menu. I would like the menu to be enabled at all times, if possible.

Thanks
Sam

 

[Olaf Doschke]

Hm, and a Top Level Form also can't be modal. Anyway there is something else making the menu inactive, is it the the menu of the top level form? Did you do it with the menu designer? Did you check the Top Level Form option in the general options?

Bye, Olaf.

 

[sdocker]

Olaf,
I tried with the top level form being Modal and Modeless. No difference.
It is the menu of the top level form.
I could not find a "Top Level Form" option in the general options.

Sam

 

[sdocker]

Mike,

Still no luck.

Every time I add a control to the container, it shows up outside the container.
What I am doing is dragging the container onto the toolbar and then dragging the controls onto the container.

Sam

 

[Mike Lewis]

Sam,

When you try to drop the control into the container, did you remember to put the container into edit mode (aka "fuzzy green line mode")?

What you need to do is to right-click on the container (from within the class designer) and select Edit from the context menu. You should then see a fuzzy green line around the edges of the container. Once you have that, you can drop any controls into the container in the usual way. To exit that mode, select any part of the toolbar outside the container.

An alternative way of putting the container into edit mode is to select it from the drop-down list at the top of the properties window. And to take it out of the mode, select something else from the drop-down list.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sdocker]

Mike,

That did it. I didn't realize the container worked like a page frame or Commmand Group.

BTW - The alternative way did not put it into edit mode unless I selected one of the controls in it.

I will have to redo the pictures properties as they now come into play..

Thanks. I can start making progress again.

Sam

 

[Olaf Doschke]

>I could not find a "Top Level Form" option in the general options.
When you edit a menu the VFP main menu also changes. In the View menu you have menu items "General Options..." and "Menu Options..."

The help says about Top-Level Form
If checked, allows the menu to be used in a top-level (SDI) form. If not checked, allows the menu to only be used on the Visual FoxPro frame.

Also read the code generated by genmenu:

* To attach this menu to your Top-Level form, 
* call it from the Init event of the form:

* Syntax: DO <mprname> WITH <oFormRef> [,<cMenuname>|<lRename>][<lUniquePopups>]

*	oFormRef - form object reference (THIS)
*	cMenuname - name for menu (this is required for Append menus - see below)
*	lRename - renames Name property of your form
*	lUniquePopups - determines whether to generate unique ids for popup names
			
* 	example:

*	PROCEDURE Init
*		DO mymenu.mpr WITH THIS,.T.
*	ENDPROC

There is more info in further comments.

To create menu code, use the Menu item "Generate.." from the Menu menu and you get a mymenu.mpr, which simply is code, a PRG with MPR extension.

Bye, Olaf.

 

[Mike Lewis]

Sam,

Glad you've got the container working. This point about putting it into edit mode applies to any object that can contain other controls, not just pageframes and command groups. So it applies to option groups and even grids (but not forms or form sets).

By the way, I see that this thread has got two separate questions, with two separate sets of answers. Ideally, you should have started different threads for each question. That way, it helps people who are searching for a similar problem, and it generally makes things easier to negotiate. It's too late to change it now, but it's something you might want to keep in mind for another time.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sdocker]

Olaf,

I was looking in Tools:Options. I found the generalptions and "Top Level Form" was checked.

The menu was generated and called as you mentioned.

To recap:
It is the menu of the top level form,
It was generated with the menu designer,
and top level form is checked.

I could not find anyplace to keep the menu active in the .mpr file, assuming that was the place to look.

Sam

 

[Olaf Doschke]

OK, I think the problem with the menu state is somewhere outside, the overall composition of menu and formset is somwhow not as thought of.

How does your main.prg start the formset?
Or are you starting this formset from another menu?
Is it the formset menu being inactive or the sysmenu?

Bye, Olaf.

 

[Olaf Doschke]

Just by the way: Formsets are really not recommended to use. Rather have single top level and in top level forms. You get in trouble with many things, eg z-order of the forms especially if several formsets run. The menu issue might also be formset related.

Define single forms and start them from each other. If you use a formset for sharing data, you can share a datasession between single forms by setting them to the default datasession and set the main/top level form to a private datasession, if at all.

Bye, Olaf.

 

[sdocker]

Olaf,

The formset is started from a menu selection which calls a procedure that determines which form/formset to run with the DO FORM command.

The formset does not have a menu.
It is the menu created with the menu designer that becomes inactive.

The formset is used to obtain the data for a 3 page questionaire. I would like a GUI similar to quickbooks(TM), where the user can go from form to form by clicking on it, and still see one or more of the other pages.

Sam

 

[sdocker]

Mike,
You're right about two unrelated questions in 1 thread. My Bad.

Sorry.

Sam

 

[Dan Freeman]

I'll double down on Olaf's comment about formsets not being recommended. They're included SOLELY for backwards compatibility with FoxPro 2.x screensets. The mess with a LOT of stuff. (Other than when VFP was initially in Alpha and Beta testing I've never used them.) I highly suspect you think they're doing something for you that they do not do.

Now, to the menu issue, how are you calling the menu program (what command?) and where are you calling it?

You mentioned a formset in a top level form, but formsets don't have a visible container of any sort so you're doing something else too.

A little more detail would help us help you.

 

[Olaf Doschke]

I still don't understand how the top level form, the formset and the menu are related, I now think you have a top level form with a menu and start a formset. We talked about the modality of the forms, but you only checked the top level form. Top level form's can'T be modal, even if you set them modal, that was already explained by Dan in thread184-1724866.

What really interests is the modality of the form started, not the modality of the form having the menu. Or more general: If any currently started form is modal the menu is inactive, unless it's the manu of the active modal form. So if any form of the formset would be modal, that would block the menu.

>I would like a GUI similar to quickbooks(TM), where the user can go from form to form by clicking on it, and still see one or more of the other pages.
I don't know quickbooks, but the simple answer to get no form blocking the activation of other forms is not making any form modal. That's all to it.

Definition of Modality:
A modal means a modal dialog, which needs the attention of a user, he has to fill in some info or make a decision, which determines how the application continues, or he has to confirm having read an important information. Eg any Messagebox is modal, even with just an OK button or Yes/No Cancel/OK, etc. It restricts access to anything else, you have to finish the messagebox first, before anything else can be activated. The same goes for any modal forms. So you also know when modality is good. You can use it for your own forms, too, but rather sparsely, if you want an application not narrowing down how users switch between forms.

Also mostly work with private datasessions, unless you want to let one form have direct influence about the record pointer positioning in another form. Typical case: a parent form shows a list, you pick a record from there eg by doubleclick and start a detail form. If you show the current record details, eg much more fields than are shown in the list, that's easy if the child form is in the same datasession, you just need to have controls to show a single record in the same way as if the controls were on the same form. But if you pick another record from the list form and start another detail form, this new form and the already started detail form would show the same current record, as all three forms work on the same workarea and it only has one record pointer, one active record. Therefore you use a private datasession, pass the id of the record to it and let the detail form use the table or tables it needs again (eg in the data environment) in their own private datasession and move to the record via the passed in ID (you pass parameters to and receive them in the Init event). Such a parent form with many detail forms also can't be done in a formset, that alone makes formsets less usable for any situation.

Bye, Olaf.

 

[sdocker]

Dan,

This is how the menu is called. .

DO FORM frmMain NAME OfrmMain LINKED && from Main.prg
DO mnuMain.mpr WITH THIS, .T. && from Init in frmMain.sct

My objective is to have more than 1 form open and be able to switch between them. If I make the first called form Modal,I cant access the menu to call the second one. If I make it Modeless, The form flashes and disappears.

From thread184-889896 I quote Marcia Atkins "The short answer here is that, because the second form is modeless, code execution does not stop when the DO FORM line in the click of the button is executed. The code continues to run."

If I do get the form to be modeless, does that mean the Menu will be enabled?

With a formset I was able to have the 2 forms in the formset open simultaneously, but the menu was disabled until i clicked somewhere on the top level form. (Outside the fomrs in the formset).

This is why I was interested in using toolbars to accomplish this. I realize it is cumbersome, but I'm hoping I can get it to do what I want.

Olaf,

>I still don't understand how the top level form, the formset and the menu are related, I now think you have a top level form with a menu and start a formset.

The top level form has a menu which calls the formset. The formset has 2 forms in it put there with the Form Designer.

How do you make a modeless form stay visible?

Sam

 

[Olaf Doschke]

>How do you make a modeless form stay visible?

You need a READ EVENTS in your main.prg

The question then is, what is your code in the menu item starting the formset? Is it really just a DO FORM? Are forms of the formset modal?

If you set every form non modal, you don't have any wait states, eg you also can't return a value from a forms Unload event, you can't do any code after DO FORM, which depends on any changes done with the form, as this code runs immediately and does not wait for the form or formset to finish, then. But you can't have both a usable menu and the ability to activate any form and start new ones, if the code starting a form needs to wait for it to finsh. Hopefully that isn't a problem.

Then all you need to do is
1. introduce a READ EVENTS after starting the frmMain form.
2. introduce a CLEAR EVENTS as a menu item to quit the application or put this in the Destroy Event of the frmMain.
3. As one of the first lines (after perhaps #includes, lparameters) in your main.prg put the line ON SHUTDOWN QUIT
4. Make all forms non modal.

To remove the formset, create single forms. A menu item cannot only do a single command. If you choose Procedure you can DO FORM form1, DO FORM form2, etc., you could also start a child form from a parent form in it's init to start two forms at the same time, though for better readable and understandable code rather start the two forms via the menu item. Anyway, there is no need for formsets for that matter, too.

Bye, Olaf.