can you enlarge tex inside the messagebox? 3

[Mandy_crw]

Hi everyone... i usually display message to inform the user of what is happening... my problem is, messagebox text are small... can you enlarge text inside it? if so, plese teach me how... Thanks and God bless...

 

[Mike Lewis]

Hello Mandy,

No, you can't control the text size in the native messagebox (other than by changing settings within Windows, which would then affect all text in all applications, which is probably not what you want).

There are however several third-party messageboxes you could use which will give yo more control over text sizes and other visual attributes. The best one that I know about is FoxyDialogs (

https://vfpimaging.blogspot.com/2020/06/foxydialogs-v10-going-much-forward-with.html).

It looks a bit daunting at first, but it is worth persevering with.

Alternatively, you could create your own messagebox. It is really northing more than a modal form with a label, an image and some buttons. You could than make the label text as large as you like.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

There are no parameters for it, no. The reason is the VFP MessageBox function just wraps a core Windows OS function you could also use with the help of DECLARE:

DECLARE INTEGER MessageBox IN user32 As MessageBoxA;
	INTEGER hwnd,;
	STRING  lpText,;
	STRING  lpCaption,;
	INTEGER wType

It gives you less options, for example it has no timeout parameter.

But the similarity is striking, these are screenshots of the two message boxes, showing they actually are the same system dialog, not determined by VFP. Even the icons and button text are coming from the OS and will also be in the Windows user language.

The good news is that this means there is a simple answer, the font size will depend on Windows settings, including those for users that are visually impaired or with low vision. This means, you let the user govern this by Windows settings, if he is visually impaired and makes use of Windows features for them, the MessageBox will have a larger font.

But the bad news is, if you go as far as you already did and take control of your form designs, background images, rounded rectangle images and other features for the design you wanted, you divert from the Windows standard theming, which goes as far as that the Windows OS solution for accessibility for impaired users is only working for the Messagebox and some other things like GetFile, which also just is wrapping a system common dialog, which look font, colors, etc. are under Windows OS control.

On the other hand, since you're not the first wanting more options I could point out several extensions that give you that. But in the end they also won't give you full control and I bet it won't end at wanting larger text.

I guess you ask because the MessageBox system dialog looks foreign in contrast to the rest of your application form design, that's just one more reason to not use the MessageBox function or any feature enriched version based on it.

Well, instead, do your own Messagebox form class.

What you need is just a label with WordWrap and AutoSize properties set .T. to allow automatic wrapping of text and automatic adjustment of the label size/height. You then can choose your own set of icons, have further buttons with other captions and functions and, well, anything you want. It's even quite simple to adjust the form height with the label height and anchor buttons to the bottom of the form, have a background image stretching and also anchored to form borders, then you have already much more in your own hands.

There's even a simple hack to keep all code as is with MessageBox calls, by a #DEFINE MessageBox YourMessageBoxFunction and implementing the same parameters as the MessageBox in YourMessageBoxFunction.prg that starts a form, sets its caption etc., waits in a modal state - just as the Messagebox does - and eventually returns the usual return values, too.

Chriss

 

[Chris Miller]

By the way, I know applications which have a very specific style not very typical for Windows, but still use system dialogs in the usual Windows-themed style. That isn't beautiful but such dialogs are used sparsely and, well, do their job, anyway. So you might also simply stick to the MessageBox as is. That's the simplest solution, of course.

Chriss

 

[Mike Lewis]

It's also worth asking why you want to enlarge the text. If it's because your users have difficulty reading the text, then they should change the text scaling within Windows, using the display options within Control Panel or its equivalent. But it should be the individual user's choice to do that - not something imposed by the developer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[tomk3]

Hello,

you may also have a look on foxclasses, the "main instruction" is in a bigger font

https://vfpimaging.blogspot.com/2020/06/foxydialogs-v10-going-much-forward-with.html

Regards
tom

 

[Mike Lewis]

you may also have a look on foxclasses,

Tom, that's exactly the same thing that I suggested in my post, above.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

But it should be the individual user's choice to do that - not something imposed by the developer.

I already touched the same aspect and second it.

But it's also valid to have your own style/design, for example by corporate identity rules. And as far as I remember Tamar Granor often already talked about the topic in conjunction with color blindness and choice of application colors. I bet there's much in her applications but also more general in VFP frameworks about accesibilty that were introduced long before they became a topic for Micosoft and Windows. The oldest help tool I remember is the magnifier you could use to enlarge anything on the desktop. If I'm not wrong that could already be used in Win 3.11, but only later was also available even before logging in on the log in screen.

But even today, as such things are embedded into Windows you have a hard time effecting VFP forms, I always recommend staying at 100% font scaling as anything other has bad side effects on VFP controls. Then rather take it into your own hands to enlarge text. Which justifies your question, Mandy. But it's then also easier to address with your own MsgBox function and form.

The possibilities of FoxyDialogs are nice and the shown examples are good, indeed. I second using that, too. But finally you already have your own form styles and designs, which you can continue to use in a selfmade MessageBox, too. I stick to that advice, still, if - as I assume - you would actually like more control than just about the text size.

Chriss

 

[JackTheC]

There's even a simple hack to keep all code as is with MessageBox calls, by a #DEFINE MessageBox YourMessageBoxFunction and implementing the same parameters as the MessageBox in YourMessageBoxFunction.prg that starts a form, sets its caption etc., waits in a modal state - just as the Messagebox does - and eventually returns the usual return values, too.

That's a nice hack Chriss. But "The constant (substitution) is available only to the program that creates the constant" according to Help on #DEFINE and my findings. If one has a project with many forms and PRG's you would need a #DEFINE statement in every form or PRG with a messagebox call in it. Is there a project wide solution also? A way to redirect all calls to messagebox() from the top PRG down to all forms and programs?

And by the way it only works if the messagebox command is not abbreviated. You would need multiple #DEFINES for every possible abbreviation.

 

[Mike Lewis]

Jack,

I think the answer to your question is that you would normally create a default INCLUDE file that contains all the #DEFINES that you want to use throughout the project. You then specify the name and location of that file via either the File Locations tab in Tools / Options, or the _INCLUDE system variable.

The point is that #DEFINE works at compile time, so the INCLUDE file applies in the development environment. You don't distribute it with your app.

Regarding your point about Chris's hack not working with abbreviated commands, I suppose the answer to that is that, thanks to Intellisense, commands will never be abbreviated. But of course that's not foolproof.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

You would need multiple #DEFINES for every possible abbreviation.

In fact, in the case of MESSAGEBOX, there are only three variations: MESSAGEBOX, MESSAGEBO and MESSAGEB. Any string shorter than that would be interpreted as the MESSAGE() function, which is quite different.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Mike, thanks for answering Jacks questions. One more thing about the abbreviations of messagebox: There's code references search&replace to bring them all to the same abbreviation or the full MessageBox. If you program in VFP9, though, you'll have to explicitly turn off intellisense to not get completion.

I will add that you don't even need to add an #include to all methods of classes, as classes have an include file for the whole class. If you're in class designer, open the Class main menu and you'll find a menu item "Include File..." where you specify this. Likewise for SCXes.

There's a good practice to let every specific include file of a PRG or class start with #include global.h or similar, so you have the chance to have global defines being loaded by individual includes. Which of course also needs the practice to have a specific include for everything, which at least needs to have that global include.

The ID also offers a "default include file" in file locations, though that's not usable to postpone a default or global include, it will just be the default include file for any forms or classes you create while that is set. And it's a bit counterproductive as you want to have an #incllude global.h just as a part of a more individual include file per class or form. Also, setting default include file does not add an #INCLUDE into prgs.

You could handle all defines by only using one global.h include file, too, which would make maintenance of #defines be editing this one global.h. You could start with foxpro.h coming with VFP, that's using that approach. it's not using #include.

You have to balance that with what it means to use third-party libraries with their own include files, if you define something that already is defined, that causes no compile error and uses whatever definition is encountered first, as far as I tested, right now.

So overall, yes, there's quite a bit of work to be done to get this going, if you didn't et use include files. But as far as I know Mandy's project it's not such a colossus that you need much work to do and while you could argue that you can also concentrate on using code references to replace all Mesasagebox calls directly, if you make it a point of your development to think about an include structure with the goal of having a global.h that's always getting to every code of the project, you have hands on global replacements without using gofish or code references. I prefer that, as it happens at build time, so you can adapt those "replacements" nd don't make them before the build. And thinking of defines as replacement is not the only use case, you know it helps a lot about the semantics of code to just have the simplest constant definitions and let your code have MB_YESNOCANCEL instead of 3.

So once you get into using includes, this all becomes natural and not far fetched to maintain and make use of.

Chriss

 

[Mandy_crw]

Thanks Mike, Chriss, Tom and everyone... youve given me so much suggestions that are helpfu to my project... God bless.