Heloo there? Is there any way to change the color [back and forecolor] of a Messagebox? Iam using VB6.0... Thanks in advance!
To the best of my knowledge, there is no way to do this. There is, however, a typical workaround.
The most common method for creating custom "message boxes" in VB6 is to create a new form in your project that acts specifically as a message box. You Show it when you need it, and then Hide or Unload it when the user clicks "OK" or "Cancel" or whatever. You can size the form the same as (or differently from) a MsgBox, create the buttons you want, make the colors as you choose, etc. Whenever you would have a message box pop up to tell the user something, you will instead call this form and change the text/color/other variables to whatever you need them to be.
This may seem annoying at first, but once you've done it once, it's very easy to see how useful a tool this new form template can become. It's code you might find yourself frequently reusing between various applications.
If you need any help with forms or form events, this is a pretty good basic tutorial which should tell you most of what you need to make this work:
http://www.vb6.us/tutorials/understanding-forms-vb6-tutorial
Good luck!
Related
I´m in that point on my app where i need to give the user the ability to save to favorites. To be more specific, let´s say that he´s seeing a list-view and then presses one of the listitems which takes him to the detail of that item...here i have a star icon that when pressed it should save that item and then if he navigates to the favorites page, he will see another listview with all of the favorites.
but i´m stuck on how to accomplish this, the only thing that comes to my mind is the application settings...it should be a dynamic array that always exists and then keeps adding or deleting objects(favorites).
Any thougts on this? can anyone suggest me an approach? maybe a better one?
Regards
You may use the nativescript-localstorage plugin which internally uses file system only and takes care of reading / updating JSON file as needed.
I am junior i C# coding, learned things in console output.
Now i am trying to understand the forms better and trying to make an app in windows form.
My goal is to do a foreach( do enumration) loop what is pinging some hosts from file.
This part i succeeded.
Now i want to present this in a form wiht the next layout.
hostname(text) ipadress(text)
i want the line to be selectable for a contextmenu.
I tried to do it in a textbox, but no succes, so i wanted to try it in a richtextbox but i am not sure if this is the proper choice.
Does anyone know what kind of control i have to use to achieve my goal, and which methods i should use.
I am not asking for writing me the whole code, just help me to think in the right way.
Your help would be very appriciated.
thanks.
Just wondering from where does the snooze pop up gets triggered when using ScheduledNotification, I mean I want to give it some effects so as to get a fancy pop up rather than just normal pop-up window. tried to check everything everywhere but could not find how to edit or override the same. Any suggestions?
ScheduledNotifications are handled by the OS, so cannot be made any more "fancy" -- if you wanted to do something different, you would need to implement that yourself, along with all the frameworks to do so.
We are designing the UI for a new line of business application. We have no real constraints and are free to design the UI as we see fit. The UI will be done in WPF and targeted for Windows 7, Vista, and XP Pro users.
Many dialog boxes contain OK and Cancel buttons in their lower right corner. Do you feel it is necessary to have this Cancel button or is the red X in the upper right corner sufficient? We are discussing this as we have been noticing more UIs that do not have cancel buttons, only the red X.
Not only you should add it but also make sure ESC is mapped to it.
Present the two designs to the customer - one with the "Cancel" button, the other without. See what their thoughts are.
Better still present them as partially working prototypes and watch them as they use the dialogs. If you ask them to perform a set of tasks and see if they have trouble when asked to cancel an operation.
Having said that, my preference is to include a "Cancel" button for the reasons others have mentioned:
Accessibility (especially as Esc should be mapped to it).
Convention (users will be expecting it).
Include the Cancel button. The red X is VERY hard to tab to. ;)
Include it. This is very common in other user interfaces. Give the user the choice of which to use; making it for them might make them annoyed with your interface.
Users are used to having standard GUI layouts - otherwise they get confused. They also have different ways of using the standard interface. Some people only use the X, some people only use Cancel. People usually ignore the one they're not using, but get confused if their one isn't present. So be safe and keep them both in - it should only be a one-liner function for Cancek anyway.
Include it!
From a user interface perspective, not including a cancel button might leave some users feeling like they have no choice, which is certainly not the case. Imagine the following simple decision scenario:
Warning: All of the files in the selected folder will be deleted. This action cannot be undone. Are you sure you would like to continue?
How silly would an interface be if the only option was Ok? Also, as noted above, on many platforms the Escape key is mapped to Cancel. It's also probably worthwhile setting a default button so that pressing the Enter/Space key doesn't inadvertently perform the action that cannot be undone.
+1 on including it. If you don't include it now and then need some different functionality on Cancel to Close later on, your users will already be used to automatically closing.
Just like we have 'ESC' button on keyboard, we need 'Cancel' in dialogs.
A matter of usability :-)
Include it. And please also make sure that you make sure that hitting the Escape key does the same thing as the Cancel button.
Also, just because you're designing from scratch, please don't throw out all convention. Take a look at MSFT's UX Guidelines for dialog boxes.
The red button is really for 'Close' rather than 'Cancel'. 'Cancel' canceling a running task. Use a 'Close' button instead. And yes include the 'Close' if there is a reason for people to click on it. The red button is quite difficult to click when you really want to close something quickly.
If you have that kind of freedom, consider eliminating dialog boxes from your application entirely, especially ones with the typical "OK | CANCEL" paradigm. Dialog boxes disrupt the flow of action and generally should only be used for things which absolutely require the program to interrupt the user.
You'll notice how disruptive they are in the web environment -- e.g., Stack Overflow only uses them when it needs to be able to OVERRIDE your action, e.g., when you navigate away from an unsubmitted answer.
I'm currently working on a program that has many of those "the user SHOULD read it but he'll click OK like a stupid monkey" dialogs... So I was thinking of adding something like a captcha in order to avoid click-without thinking...
My ideas were:
Randomly change buttons
Randomly position buttons somewhere on the form
The user must click on a randomly colored word within the text he should read
add captcha
add captcha that includes the message for the user
Has anybody made any experience with such a situation. What would you suggest to do?
Well, you asked for opinions and here goes mine, but I don't think this is what you would like to hear...
Users like programs that they can depend on. They don't like when things change and they don't like to do extra work.
Randomly change buttons and Randomly position buttons somewhere on the form will only make them either press the wrong button or become annoyed with your application, because as you say, they don't read the text, and if you think about it, neither do we. As an example think of an Ok/Cancel dialog, you allways expect the ok button to be on the left, and most times i press it without reading it. It Will happen exactly the same with your users.
The user must click on a randomly colored word within the text he should read
add captcha
add captcha that includes the message for the user
With these 3 option you will add extra work to your application, your users will curse you for that. Just think of something that you would have to do 10x per day, let's say check in your code to source safe. How would you feel if your boss told you that from now on you will have to fill a captcha for each file you try to check in?
I think it's our jobs to make the lives of the people that use our software easier. If they must read some kind of text and they don't want to, there is absolutely no way you can make them do it.
You can´t make people work right, all you can do is provide them with the best possible tools and hope that they are professional enough to do their jobs.
So basically all i'm saying is, do your best to ease their work. If this is really important than you(or whoever is in charge) should talk to them and EXPLAIN WHY this is important.
You would be surprised on how people commit to things they understand.
I suggest that you don't; and that, unless you know better, you emulate respectable well-known, well-tested UIs like <big online retailer's> or <online banking site>.
Playing games with the user in order to get them to read messages is doomed. Users will focus mental resources on completing your game, rather than understanding the message. Your users may be less likely to actually understand the important part of the message if you have things like moved buttons, relabeling, scavenger hunts, captchas, or delays. They’ll focus on the instructions for the game, not on the real issue. Errors are likely to increase.
Users’ refusal to read message boxes is due to users wanting to get things done quickly rather than take the time to read stuff, and it is also due to message boxes being overused and misused so badly in so many apps. Including silly games in message boxes will just make users resent them all the more, compounding the problem.
Here’s what you can do:
Rule 1. Don’t use messages boxes. They should only appear for exceptional circumstances. An app should not have “many” message boxes. It should not be necessary to read a whole lot of documentation each time the user uses an app. If normal use of your app results in a message box, then your UI is wrong. Find another way.
Instead of verification messages, show clearly in the main window what has happened and provide a clear way to Undo it.
Use auto-correction, pictured/masked fields, and disabling rather than error messages.
Use good defaults and automation to avoid messages. For example, rather than showing an error message saying the user can’t upload because they’re not connected to the server, simply reconnect automatically.
Break commands along options. Rather that a message box to ask if the user wants paste with or without format, provide two different commands in the menu.
Don’t have information messages spontaneously popping up telling the user everything worked fine (e.g., “Preferences Saved!”)
Don’t have pop-ups providing helpful hints or documentation. Provide a tutorial or balloon help if you can’t make your UI self-documenting.
Don’t have nagging “upgrade me” messages.
Consider providing message text in the main window rather than in a separate message box (e.g., “Page may not look or act right because ActiveX is off for security.”). Pop-ups from web surfing have conditioned users to automatically dismiss anything that pops up as irrelevant.
Rule 2. If you have to use a message:
Make the text as brief as possible to get the key information across. More text is not equivalent to more helpful. Use “No match to [filemask] in [path].” Don’t use “Nonfatal Error 307: Search action aborted. [Appname] is unable to complete your string search for the regular expression you provided because the file mask you gave, namely [filemask], does not result in any matching files in the directory that you specified (which was [path]). Please check your filemask or path selection and again re-enter it or them in the Files to Search dialog box. Click the OK button below on this message box to return to the Files to Search dialog box. Click the Cancel Button on the Files to Search dialog when you get there to cancel your search for strings.” If there are some users who will need more explanation than can be achieved in a brief message, provide a Help button or a “How do I…” link in the message box.
Use plain language and no jargon in the message. That includes “innocent” words like “dialog,” “database,” and “toner.” Do not take raw exception text and throw it in a error message. Do not include any error numbers or dumps; log these instead. Purge your app of any debugging message boxes left by developers. Better to simply let the app disappear on a fatal error than to put up a message full of jargon and then the app disappears.
Label the buttons of a message box with what the action does, not “OK.” At the very least, the users have to focus on the activating button to dismiss a message box. If that button is labeled something like “Delete” or “Install,” it should give them pause. You should never have to explain in your message text what each button does. BTW, such labeling is a GUI standard on most platforms.
Redesign your application so that it does not use message boxes.
My suggestion, live with it or redesign your dialogs/interface. Do not add randomness to dialogs or otherwise treat the user like an idiot, even though you may think most are :-).
I just recently read a Joel on Software article, Designing for People Who Have Better Things To Do With Their Lives. It makes the point that most people won't read anything and discusses ways to work around that or at least not make it worse.
You could try with a timer which waits for the "supposed reading time" before enabling the submit button. You can even calculate the supposed reading time from the number of words.
I think that subtle ways to force the user to read your text (like moving around buttons or asking them to read a captcha) can make them feel like stupid monkeys.
You could use a choice question based on what the user should read.