Customizing browse and modify memo 1

[dmusicant]

I have an app I use a ton. Instrumental are a browse of a table and going into a memo field. Seeing the memo field tends to remember my last font size, which is important to me because 8 or 9 is way too small and I usually set the font size to 14. However, in a lot of tables it defaults to a small font size and I have to increase it with a series of mouse clicks. If I could get the memo fields to always open at 14 point, that would be great.

A more serious problem is that browsing one of the couple hundred tables in the app ALWAYS defaults to a too small font. I usually just live with that and increase when I need to, but I wish that VFP 9.0 would remember the last font size in the browse for any particular table, or even for all tables in the app. As it is, if I increase the font to, say, 14 point and close the table, next time it opens the font size is always back to 8 point. I am using BROWSE PREFERENCE, so it remembers the field order I want and the size of the columns, but it doesn't remember the font size, which seems to me a shortcoming of the BROWSE or BROWSE PREFERENCE command. Am I missing something? Do I have to rewrite my app and start using grids to get the control I want?

 

[dmusicant]

Well, well... I went into my code and see that I was specifying font size 8!!! Size 9, once. I changed that to 10. Still, it would be maybe better if it would just remember the size when the table's browse was last closed and start with that.

 

[TamarGranor]

All that stuff is remembered in the resource file, FoxUser.DBF, as long as you have SET RESOURCE ON.

That said, Browses don't belong in VFP applications. Grids are much easier to manage.

Tamar

 

[dmusicant]

Yeah, I have RESOURCE ON. That's machine specific, I believe, so a change I make when using one machine won't transfer to another. It's a minor issue. Changing the default browse to 10 point from 8 a few minutes ago is a big improvement. I may try to get the browse to open in the last size used, will think about that.

Yes, I had a feeling that GRID is apt to be a lot better but I've never used them. I suppose I could transition my two main apps to use grids instead of browse windows. If I only knew!!! IOW, I'm unaware of the advantages! Maybe there's a page somewhere that will inform me? I wrote these apps in FPW 2.6a, and they still work in it but I use day to day in VFP 9.0. The only reason for maintaining FPW compatibility is so I can edit/modify the FPW screens, of which there are several. However, I could maybe use grids instead of browses, a great deal of the functionality is embedded in extensive PRGs, not much in screen code.

 

[Mike Lewis]

Why not record a keyboard macro that would enable you to change the font size with a single keypress?

Go to the Tools / Macros / Record, and specify a keypress (that is, a combination of keys, using ALT, CTRL, etc.).

Then record the following keys:

[tt]ALT+A F ALT+S 14[/tt]

(without the spaces shown above).

Finally, stop recording.

From now on, whenever you hit the specified key (while a Browse window is open), the font size will change to 14 (or whatever you set it to).

You can save the macro to a file for later re-use, automatically load it on startup, and transfer it to another computer. If you need any help with those tasks, see Use keyboard macros to speed up repetitive actions.

Having said all that, I agree with Tamar that a grid is a better way to go. But using a macro with your existing browses will be easier to implement.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The Tools -> Options also offer a default you can use for all browse windows:

In the IDE tab change type to "Memo Fields"
On the righthand side pick font and its size with the font dialog, you start by the [...] button.
check "override individual settings" and all Memo Field windows will open with the larger font size.

And of course this and resource settings are per machine, neither of that is stored in dbfs themselves, there is no section in the DBF header foreseen for such settings, so how should another machine know your changed resource or IDE settings? Even if you store your foxuser.dbf on a centralized share you can access from each of your development PCs, you won't have fun with it, as VFP needs it exclusive.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[dmusicant]

Great suggestions, I will implement... thanks!!!

 

[Koen Piller]

Hi,

Maybe there's a page somewhere that will inform me?

although not in English, I suppose good to study:

https://www.youtube.com/watch?v=QvQh0RdZmj0

also good to study :

https://www.youtube.com/watch?v=GLcQWPoZjOY

in general use your internet browser search machine and search for 'VFP tutorials youtube'

And the very best advice I can give you: buy 1000 Things I wanted to know about Visual Foxpro

Regards,

Koen

 

[Mike Lewis]

Dan,

If you are interested in learning how to use a grid in place of a browse, it's really very simple.

1. Create a new form.

2. Drop a grid onto it.

3. Write this code in the form's Init: [tt]THISFORM.Grid1.RecordSource = ALIAS()[/tt]

4. Save and close the form.

From now on, any time you want to browse a table:

1. Open the table, or switch to its work area.

2. Run the form.

This is very basic. The form will always display the table in whichever work area is current when the form is opened. If you switch work area, the form won't reflect that. If you close the table, the grid will go blank. But those limitations are not too severe, given that they also apply to a Browse window.

To improve the form:

1. Resize the grid so that it fills the form, then set its Anchor property to 240. That will ensure that it resizes as you resize the form.

2. Set the grid's FontSize property to an appropriate value. While you are there, you can also set other cosmetic properties, such as FontName and ForeColor.

3. To make the form work with any table (without having to open a new form when you want to browse a different table), place a button on the form, set its Caption to Refresh, and put the same code as above in its Click event: [tt]THISFORM.Grid1.RecordSource = ALIAS()[/tt]

It's still fairly basic, but it will be a step up form a Browse, and will solve the specific problem you asked about.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

While all that is true, Mike, in tself it doesn't change the Memo Windows popping up if you click on a populated Memo field with the big M caption in it, that is still the same as with a browse window.
Overall, the way you suggest to create the form, it resembles a browse ver much. You can do more with both a browse and a grid, as they are essentially the same anyway. With a grid on a form you now just have many properties available and showing up in the property window, you can set captions of headers, just like a brows can show captions you define for a DBF (IIRC only for DBC related DBFs), but many more things come apparent, like DynamicBackColor or other Dynamic properties.

You can have some if not all of this if you BROWSE NAME oBrowse and then use that oBrowse variable name to reference all the properties a grid has. Just for the record, do:

Use browser
Browse name oBrowser
oBrowser.FontSize =16

What the grid has as advantage to browse is, that it's a control. You can actually put controls onto any window including _screen, as they are all forms, but when you start using controls that's also the time to switch away from @SAY and @GET and all the von Neuman mainly sequentiel code in screens and rather go for event driven forms. You don't force users through a specific order of events and input, you still can and diaabling controls is a way to control what users can use, but in general a Winform gives you a bunch of controls to use as you like, to focus or tab to any way you like and I guess you can also do such things in FPW, reacting to mouse activation, but aas far as I've seen screens they are really made to be processed seqentially, very straight forward logic to write them.

When you go for forms, forms bound to data pretty much do everything to let a user read and edit data without any further code, so your code can concentrate on the functionality you want to implement, reading data from a dbf, scattering it to memory variables and then gathering it back isn't needed, instead you either introduce buffering to be able to revert changes, or you bind so directly, that editing in a textbox or whatever control means the data already is going back to the dbf when the user tabs to the next control.

The thing to get used to is code being scattered in small portions in init, click, interactivechange etc. events. But you have to see that as the advantage of needing no code but only the form description by controls and their properties to have all visual stuff and data binding done with just configuration and then concentrate on the code that should execute if someone clicks a button.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[dmusicant]

I just tried setting up a macro per the instructions above:
- - - -
Why not record a keyboard macro that would enable you to change the font size with a single keypress?

Go to the Tools / Macros / Record, and specify a keypress (that is, a combination of keys, using ALT, CTRL, etc.).

Then record the following keys:

ALT+A F ALT+S 14

(without the spaces shown above).

Finally, stop recording.
- - - -
Can't get it to work. The process of creating it is confusing to me. I'm talking about a browse window and a macro to change the font size to 14 here. Every thing I've done doesn't work. I tried editing it, too. Can you post what the macro looks like unedited. That is to say, what I'll see in the window presented when I ask to edit it? Thanks.

 

[Mike Lewis]

Dan,

I didn't intend you to type the keystrokes into the macro editor. My suggestion was that you record the macro. that would have generated the keystrokes for you.

Having said that, I must apologise for telling you what to do without first testing it myself. I see I made a couple of mistakes. I forget to tell you to press {ENTER} to close the Font dialogue. And for some reason I don't understand, ALT+S doesn't seem to correctly move focus to the font size control within the Font dialogue. Replacing ALT+S with two TABS seems to solve that problem

One other issue: it's possible that the macro needs to pause for a few milliseconds to give the dialogue time to open. (I'm not completely sure about that, but it's worth putting it in to be on the safe side.)

With all of the above in mind, here is my new version of the macro:

{ALT+A}F{PAUSE 0.01}{TAB}{TAB}14{ENTER}

Copy and paste that into the macro editor. You should have assigned it to a shortcut key, say, CTR+P. Save the macro to a file, as described in the article I told you about in my earlier post.

From now on, whenever a Browse window is in focus, hit CTRL+P (or whatever key you specified) to make it 14 point.

Again, apologies for not getting it right first time.

Final point: Keep in mind that you can always do [tt]BROWSE LAST[/tt] to open a browse window with the previous settings, including font size, even in a different VFP session (but only for the same table).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Thanks, Mike. That works. I had the same macro (pretty sure) except that I didn't have the pause in there. There was one point where it was suggested by VFP 9 that I insert pauses, but I didn't do it... meant to try it but couldn't remember where it asked me that. The whole macro handling gamut in VFP confuses me... never dealt with it before. I was offered to save it in a file, have no idea what you do with the file but I did save it. In any case, once created, saved or no, it's working. I assigned to F12, not Control + P, which is obviously more complicated. Don't know a downside to using F12. If F14 were available, I'd have used it, of course!

 

[Mike Lewis]

I suggest you go refer back to the article I mentioned in my earlier post. It explains the whole macro thing in some detail. I'll post the link again here: Use keyboard macros to speed up repetitive actions. (It also mentions some other possible uses for macros.)

Re the choice between CTRL+P and F12, there is no functional difference. It's just a matter of choosing a key combo that you are comfortable with, and which doesn't clash with anything else (so CTRL+O would be inadvisable, because it launches the File Open dialogue for example). My choice of CTRL+P was just a suggestion.

The reason to save the macro to a file is so that you can re-load it in the next session and use it again, without having to recreate it. You use the [tt]RESTORE MACROS[/tt] command to load it; and you can put this in a start-up program to do that automatically.

Re the need for the pause, I don't really understand why that's necessary, but it does seem to make all the difference in this case.

Glad to see you've got it working now. One issue we haven't resolved is how to set the font size for the memo editor. That will need more thought.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Makro files help you to load it, just like DBF store data. Within the IDE loading your definitions as its configuration you may never need these fky files, but this feature can also be used in applications.

I'd suggest you use macros with hotkeys other than CTRL, many CTRL keys are system hotkeys and I actually struggle maintaining an application overloading default hotkeys like CTRL+C and CTRL+V...

CTRL+P is typical for printing screen and CTRL+S for saving current edited text, code, documents... Make it ALT+M for example as ALT Memo size.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[dmusicant]

Oh boy. I got the idea to write a couple more macros and save them in the same FKY file. F12 sets font to 14. F11 sets to 12 and F10 sets font size to 10. F12 and F11 work as described but F10 closes the browse! Don't know what's up with that.

Another quirk is that when I save a macro such as:

{ALT+A}F{PAUSE 0.01}{TAB}{TAB}14{ENTER}

If I go to edit the macro I just saved, here's what I have:

{ALT+A}F{PAUSE 0.00}{TAB}{TAB}14{ENTER}


IOW, it converts the PAUSE 0.01 TO PAUSE 0.00. Yet the macros work, except for the F10 macro, as I say, which just closes the browse window. That macro reads:

{ALT+A}F{PAUSE 0.00}{TAB}{TAB}10{ENTER}
- - - - -
Complicating the issue here: I placed my command RESTORE MACROS FROM <MY MACRO FILE> in my startup program and it didn't work. Placing it in the PRG that sets up the browse does work. This is very likely due to the fact that I have other FKY files in my app! I'd forgotten about them entirely, but I see the FKY files in the directory with all my other code. I'm going to do some sleuthing and find out where I call FKY files and try and determine what I have going on there! If I need other macros, well, I will have to integrate them with other stuff I'm doing including this set which is designed solely to alter the font size in my main browse window.

 

[Mike Lewis]

The reason that F10 doesn't work might be that this has the built-in function of invoking the menu bar. This is a Windows function, and probably cannot be overridden in VFP.

Rather than having a separate macro for each font size, you could have a single macro, but have it stop at the point where it enters the font size, which you then enter manually. In other words, your macro would be as follows:

{ALT+A}F{PAUSE 0.01}{TAB}{TAB}

After hitting F12 (or whatever), the font dialogue would be open, with focus on the font size control. You then type the two digits for the size that you want, and hit Enter. So, to set it to 12 point, you would do F12 then 12 then Enter. That's three more keystrokes than with the original macro, but you would only need one macro for all font sizes and one shortcut key.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Another idea, let the macro write a default font size of 12 and just don't {ENTER}m the user then can take 12 via Enter or backspace and enter 10 or 14 or whatever.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[dmusicant]

Thanks for the further tips on macro changing font size in browse window. Very helpful. Will check out adjustments to code that could help adjust memo field font and font size. My resource file on any particular machine does remember my choices for any particular table but I frequently encounter a situation such as Courier font at size 8 and have to choose my font, then size.
- - - -
Don't know why but I can't find the facility to quote others' posts in threads.

"And the very best advice I can give you: buy 1000 Things I wanted to know about Visual Foxpro"

Well, that was above. I have, I think, the great majority of the Hentzenwerke VFP books and that one included. I confess, I don't think I've done anything with that book yet. I have it at my elbow now, however. The correct title is "1001 Things You Wanted to Know about Visual FoxPro"

Authors:

Macia Akins
Andy Kramek
Rick Schummer

Edited by John Hosier

I suppose I have the download supplements for it as well as for the other titles from Whil Hentzen.

 

[Olaf Doschke]

If you want some setting for every browse or memo window or code window, the Tools-Options IDE has the "override individual settings". Just first pick the window type, this override option is an optoin per window type.

And don't forget to exit the dialog with "Set as Default".

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name