How to set font size and type in TXT file thru VFP6/9 3

[Piotr Czekalski]

Hi all,

is it possible to programmatically apply font to display text files by command Modi Comm File.TXT - preferably when starting program ?

I use "Modi Comm File.TXT NoEdit" command to display reports (text files contents). I manually set font via: Format-> Font and then Edit->Properites->Apply to TXT->OK. After some time VFP assigns a different font to display TXT files. Then displayed reports lose their format. I taught my clients to manually set the appropriate font format and size themselves, but it's a problem. I use Modi Comm commands in programs in many places in code. I'd rather not change that solution.

Thx for help

 

[ggreen61]

In the design-time environment you can set the font default from the menu path:

Tools --> Options

Then go to the tab IDE and set the desired font name, size, etc. This will generate a setting in the registry. Possibly if you export this setting from the registry and then import into your customers systems, and maybe it will use/retain the font that you want.

 

[Piotr Czekalski]

Thanks. In one client's my font settings work for a month, another for 2-3 weeks. Windows updates probably break it or updates to other software. For some clients my settings don't change at all - remains stablity. If you mean Windows registry I can't import them to my clients system. My client's IT departments won't let me do that.

 

[EinTerraner]

You can use FOX to read/write the user-settings in the registry.

 

[atlopes]

Piotr,

You can define a window with all required settings and modify the report in that window when needed.

DEFINE WINDOW EditorWindow FROM 1,1 TO 40,80 FONT "Arial", 14 TITLE "Editor Window" CLOSE FLOAT GROW
* the definition is now available
* first use
MODIFY COMMAND report1.txt NOEDIT WINDOW EditorWindow
* second use
MODIFY COMMAND report2.txt NOEDIT WINDOW EditorWindow
* and so on...

 

[Chris Miller]

I think atlopes has a good solution. I'd go for putting the text into a memo field and use MODIFY MEMO. But I'd like to address your false assumption.

Windows updates probably break it or updates to other software.

I strongly doubt that. Why would Windows updates fiddle with FoxPro registry entries In the HKEY_
CURRENT_USER hive (that's where they are, see below)?

This argument for anything people don't know how it changes is assumed to come from the outside, i.e. Windows Update or other outside effects is most often not true. I remeber tons of such finger pointing and only know 3 things of the top of my hat that actually are Windows changes, PACK, GENERAL fields behavior and printer setup dialogs.

It has never happened to me that due to a Windows update my VFP editor windows settings changed. In VFP you make settings of fonts and sizes, more generally for "Appearance and behavior", as it's called in the Options dialog, IDE tab for all kinds of windows of program files, memo windows and more. On the lefthand side of the IDE tab pick a type of window and you see the used font face, size, also set whether syntax colouring is used, hyperlinks are rendered as such etc.

All IDE window appearance settings are stored in HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualFoxPro\9.0\Options\IDE.

If you mean Windows registry I can't import them to my clients system. My client's IT departments won't let me do that.

And that the appearance of MODIFY COMMAND changes is proof enough there is no restriction on this registry hive. Because those settings come from the registry.

Did you know the registry is stored in files, one for each key hive (like HKEY_LOKAL_MACHINE, etc.)? Part of that is per user and if there would be a policy restricting even the access to the users hive, there would be no appearance changes, and you would also never be able to direct users to make changes they way you described with menu options.

Well, take all that aside, the solution suggested by atlopes doesn't even need registry changes or IDE settings changes, as it just prepares a window with what appearance options you like. So I don't even need to hammer on the point you could also do registry changes, as they are obviously possible. Defining a window gives you control about that windows settings without influencing the appearance of all similar windows. The user has the ability to change appearance with context menu (mouse right click or context menu key) in properties. That also only applies changes to that current window, not all others. So overall, it's less intrusive to VFP users choices of IDE default window appearances.

 

[Piotr Czekalski]

Ok.

Command "Modi comm ... Window" is a very good solution that I know and sometimes use. There is one problem. My reports require scrolling vertically and horizontally. After calling command: "Modi Comm .... Window" ScrollBars (Screen1) are not visible. They appear after manually resizing window (Screen2). This confuses a little users. That is why I have not used Window clause in reports so far. This would be the best solution. How to make ScrollBars appear immediately after opening a window.

Screen1



Screen2 (after manualy resizing)


When I asked question in main topic I wanted to avoid changing the program code in many places where I display reports. I guess it will not be possible.

Thanks ggreen61, EinTerraner. Maybe we can solve the problem without updating registers.

Chris, what could be the reason for changing the font assignment ?. Some process is probably updating Windows registry.

 

[Chris Miller]

Updating the Windows registry is possible by any process. But even if a Windows update is celaning up registry entries with infos for bot nets (I think that happened more than once to deminish spam bot nets), why should it explicitly change the VFP IDE window settings? It's not Windows settings af general appearances of Windows, those registry settings are explicitly only for VFP windows, nothing else in the system. They are not about the default font for Windows in general, Windows colors, etc.

What can change the specific entries of the VFP IDE windows appearance? FoxPro. Users using FoxPro aking changes not realizing that affects your report display windows, as they don't even know you're using MODFIY COMMAND for them.

Again, the registry key for program windows is the only key determining the font of the MODI COMM windows. It's really pinpointed down to this one registry entry for that. Users using Foxpro not only within your software (you know MODIFY COMM is not available in the vfp9r.dll, users will need VFP installed) are setting up their editor windows as they like, don't they? And thus they change settings you make for your report display, using MODIFY COMM.

If you don't like changing lots of code, then the only thing you can do is change the specific registry key, thus fiddling with their code window appearance choices. You'll still be going forwards and back, then, when users don't want your report font/fontsize etc. choices for their code editing.

 

[Piotr Czekalski]

There are many ways to display text files in VFP. Not all of them are supported horizontal scrolling. Modi Comm, Modi File seemed to be the most stable, although better to be careful about right-clicking on a piece of text to highlight. VFP can get stuck when clause NoEdit is used.

What is interesting, Windows system program NotePad blocks access to options in VFP: Edit-->Properties-->Apply to TXT. I noticed that running several VFP programs at the same time causes the disruptions font of txt files display I wrote about. But after closing programs everything is OK. Now I have an idea. Problem may occur if client runs several programs in VFP in the same time and closes computer. Then all will be saved and confirmed in Windows registry. Current (incorrect) status of font assignment to display text too ...

 

[Chris Miller]

Windows system program NotePad blocks access to options in VFP: Edit-->Properties-->Apply to TXT

No, you just have a wrong assumption that this VFP option sets properties like the font used for the TXT extension and thus the whole Windows system. You only set the option for VFP using MODIFY FILE or MODIFY COMMAND, Notepad has it's own settings that are also not subject to Windows cofiguration. If you change font in Notepad this is stored somewhere, I guess the regisry, as a notepad setting, it's not applied to the TXT file you have loaded. A TXT file only has one influence of Notepad that's also mainly only applied by Notepad itself, the first file bytes, if used, can make it an ANSI, UTF8 or Unicode text file. Notepad++ as intended third party replacement editor for Microsofts notepad is also knwoing this (called BOM), but there is no embedding of font information for TXT files, within TXT files are alterative NTFS streams associated with a file.

You're thinking of Windows settings, where they don't even exist.

 

[Chris Miller]

Lets talk about the inverse, lets focus on the defaults you can set in Windows overall configurations. in the section of Themes. Actually since at least Windows 10 Microsoft has shrinked the options users had to set the font of Windows Titlebar captions, for example. Within a few minutes I spent on this I only find the general font size setting you can make, nohing more. Might be still available for backwards compatibility, but I won't dig that deep for now.

Even when those things have been configurable, VFP forms for example, would by default inherit the Font and Fontsize used in forms from Windows, but you can override them as you like. The main settings you can actively read in from Windows are only osme for decimal point, currency symbol, etc you get from SET SYSFORMATS ON.

One of the other things is the Form class property "Coloursource", where you can pick from 0 (default) Objects own colours, 4 Windows Control Panel (3D colors) or 5 Windows Control Panel (Windows Colors), which I think are both outdated with at least Windows 10. Mainly that gave all Windows the same "Windows gray" in NT, 95/98/2000,XP etc versions.

The theme influence of Windows has been reduced to what font all Windows Titelbars are, the flat vs §d look of controls also is influenced by Windows, but I don't even find a default font setting for say Text or Editbox like controls anymore, that I knew from Windows NT-XP.

 

[Chris Miller]

By the way, it's more straight forward to use MODI FILE for TXT editing or display (with NOEDIT option), but VFP has no registry key explicitly for any file (MODIFY FILE allows any file extension, mainly txt, but not only). I think MODIFY FILE will use the same settings as MODIFY COMMAND, these two commands seem to only differ in whether you get syntax coloring or not.
But they are not Windows settings, that's clear.

You can resuse most of your code making the registry setting for Program Files, but would be better off and in full control by changing to establishing your own Windows. I can't reproduce the scrollbar problems you have. Even if, you can set them, too, once you have a legacy window name, you can get an object reference ot it and set form class properties such as Scrollbars:

Define Window MyWindow FRom 1,1 to 40,40 ... NAME oMyWindow
oMyWindow.Scrollbars=3

Notice the distinction of the WindowName MyWindow and the object reference variable name oMyWindow. You could make them the same, but the former is used in all WINDOW commands and functions like WFONT(), the latter is usable as object reference for OOP VFP code making use of any properties.

There's an overlap of usabililty. For example, later on instead of DISPLAY WINDOW MyWindow you could also use oMyWindow.visible=.t., etc.

So in main.prg define a window for all report displays and the only thing you need to change in your MODIFY COMMAND is adding a WINDOW EditWindow, that's doable with Code References Search& Replace.

 

[Chris Miller]

You might think the idea of defining a window to rule display them all fails on the Window being closable and so getting released after the first display of a report txt file, well, as shown you can have a for reference and set closable=.f.,, also use BindEvents to have code in the QueryUnload not allowing to close the form and instead hiding it.

Edit: After a bit experimenting it turns out that once you define a window as atlopes suggest with DEFINE WINDOW and add a NAME oReprotDisplay clause to it, the object reference isn't really identical to the Window. For example oReportDisplay.Scrollbars=3 doesn't add scrollbars. So that idea fails, unfortunately.

But you may turn it fully upside doen and make a form class for report (txt file) display instead of using MODIFY COMMAND you shange it to showing that form with text file to display as parameter of the Show() method and Hide it in QueryUnload or even turn it to a DO FORM instead of MODIFY COMMAND.

 

[Piotr Czekalski]

Chris, I highly appreciate VFP as tool for processing text DBF tables. Support is extremely effective compared to other XBase systems. Used at the appropriate scale of course.

I am a client of a small company that creates software in VFP9 for handling tax returns and financial reports. They have full support for XML, cryptography, electronic signatures, etc. All these documents are sent to government servers in some mysterious way. This is already space for me. I just export data from my stupid programs to this program in CSV format. They developed it all themselves. So VFP has potential. I appreciate it.

Sorry for small offtopic

I'll be working on these fonts on all Saturday

 

[Chris Miller]

I wonder if our posts crossed over. In short my idea didn't work as expected, but the idea to replace all your MODIFY COMMAND lines with something else, with the help of Code References or also GoFish or something you wirte yourself would easily work. and then you can also replae a 1-line call of MODIFY COMMAND with multiline code. The only bummer is, that you likely don't want to replace each and every MODIFY COMMAND, as not all of them are about report display, but I'm sure you'll find a way to make the search only change the relevant MODIFY COMMAND lines.

 

[Piotr Czekalski]

I used the clause "oMyWindow.Scrollbars=3". Sometimes ScrollBars appear, other times they are not visible. I don't understand at all what this is about.

That's exactly Chris what I'll do. All Modi Comm and Modi File will be changed to a call to a procedure that I'll write using object programing : forms etc ... .

 

[Chris Miller]

All Modi Comm and Modi File will be changed to a call to a procedure

That's the way to do it, right.

The object variable you get from DEFINE WINDOW ... NAME oMyWindow is clearly a form class, but it's still not yet exactly the Window defined. I made the same experience as I wanted to establish a hidden ReportDisplay Window with Scrollbars to use with MODIFY COMMAND or FILE. But when you specify IN WINDOW you get a window within the Reportdisplay window, that's not working as intended, if you instead write MODIFY COMM ... WINDOW ReportDisplay, not IN WINDOW, that overrides the existing Window. So you get strange effects any way you do it and I came to the conclusion to better replace this with atlopes full code. And then, right, it's a best approach to put that into a class or procedure to call.

There's still a no changes required approach, if you set registry keys for PRG Windows in main for this applications session and stay with MODI COMM. It just overrides the VFP programmers setting everytime using your application.

Anyway you go through it, I wish you find all relevant places and sucess in the details.

 

[Piotr Czekalski]

Chris, I'm working on this problem and have some ideas. Maybe it will be work.

I started experimenting with registry keys. I changed my favorite Screen-1 font "FoxFont" to Franklin by (Format-->Font and Edit--->Apply to TXT). FoxFont was once developed by a colleague of mine specifically for my needs. I don't want to go into details. I turned my computer off and on again. Fox-Pro remembered the Franklin Screen-2 font setting. I checked all Windows registry keys by RegEdit for VFP9 one by one and there is no font named Franklin. Additionally, I used search engine. I found Franklin among other fonts in Office Screen-3.

This sneaky VFP probably saves these settings somewhere else.

<<Personal data, surnames, names generated by "AI">>

Screen-1


Screen-2




Screen-3

 

[Chris Miller]

I pointed out VFP stores several windows font settings in HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualFoxPro\9.0\Options\IDE
Let's look at this in more detail:

This registry branch has 4 font settings, while the dialog Options->IDE->Type pffers 8 different window types.

Sp there is no 1:1 mapping of window types with the font settings in the IDE registry branch, obviously.
The options set appearence for IDE window types, not for file extensions. File extension associations are reg keys in the IDE branch, but this is mainly about IDE window types, not file extensions. File associations of the Windows systems are about standard applications, and font associations therefore are not about file extensions but about applications configurations. So all file extension VFP handles would get their appearance from the IDE branch, unless there is no font key, like for example for TXT.

What I think is very straight forward is the VFP reg key for Program Font, as that would be used by MODIFY COMM. The file extension ProgramExtension key is set to PRG, but also others MPR is menu program (generated by genmenu), QPR is for query program, that's a specialty I wont get into, and SPR I think is for snippets or for screens. Well it doesn't matter much, as you know you can also MODIFY COMMAND Text.txt, it's not really bound to PRG,MPR,QPR,SPR

So I would have set ProgramFont and use MODIFY COMM.

What you don't have is a special key for TXT, or better said for MODIFY FILE. So either VFP stores that setting elsewhere or it's also determined by ProgramFont.

Anyway that is, with Program Font you're in control about how windows appear you open with MODIFY COMMAND. One of the appearance settings that's not in these registry keys is syntax cololuring, and I guess MODIFY COMMAND causes a window appearance to include syntax colouring, which is something you likely don't want.

Overall, that gives you less control than I first thought. But there must be somewhere VFP also stores your decision to have or not have syntax colouring. What's less good about using MODIFY COMM is that programming with VFP you surely want syntax colouring, so setting that off for report display windows will always be opposite of what developers will set.

That's speaks for finding a way to influence the appearance of MODIFY FILE, but maybe it would work, if you change to MODIFY MEMO. That would require a code change anyway, all report output txt files would need to be read into a memo field of a dbf or cursor.

I don't know if you have general, centralized routine that all report outputs to txt go through to get to the txt display, then it would be simple to read in txt files into a memo, generally.

Edit: Looking at the reg keys (and refreshing them with F5) I see the syntax colouring is a "bit" in the data of the Program registry key, I think in the 11th position. I say "bit" in quotes as the data also includes 4, not only 0s and 1s. No idea what this is all about, but the registry key type REG_SZ is just a text. If you set this to what you need and set it back at application end, you're in control about the appearance of windows you get from MODIFY COMMAND, I think. And that is your best bet on having the least program code changes by only setting registry keys.

Edit2: Is MODIFY COMMAND only available in the IDE and not with the vfp9r.dll runtime? I think it is available, editor windows are not limited to the IDE only. There's one completely new possibility, if the runtime will also respect the TEDIT setting within a fpw configuration used by your application, then MODI'FY COMMAND will run whatever application you specify there, that could be notepad++ or anything else, also an own EXE you use for display, and then you'd be in full control about the look of it. So that wouldn't even require fiddling with the registry keys, but instead making use of TEDIT=some.exe in a fpw file you use within your exe by start parameter -c or having a config.fpw in the same folder as the exe or (I think) embedding a config.fpw inside the EXE with a TEDIT line.

 

[Chris Miller]

Simple experiment about the TEDIT idea:

I made a simple project having an embedded config.fpw with TEDIT=Notepad.exe, a main prg that does nothing else but MODIFY COMMAND (GETFILE()) and running that exe, choosing a file I get notepad up to display the chosen file. The only disadvantage is that not only notepad but a cmd.exe windows comes up. I think you could influence that somehow, then this would allow you to define your own exe instead of notepad.exe which gets the file name as first parameter. And then you neither change settings of VFP nor the IDE configuration with a config.fpw and have full control about the display.

I think the visibility of cmd.exe can be controlled with the FoxRun.pf in HOME()+"Tools".