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 just beginning to learn about accessbility specifically in relation to JAWS - so newbie alert!
I am looking to modify an old vb6 app which has a form with a 3 column flexgrid. There is a custom edit box which is overlaid on the form for editing in the right most column. On row change, ideally JAWS needs to read the contents of the 2 leftmost columns on that row.
I am wondering how best to implement this?
I have seen possible solutions of loading into a text file and shelling out to JAWS on a row-change type event. This seems a bit heavy but maybe it is a good solution.
I have also read about the IAccessible interface. This sounds like a good solution to me, but I don't know if it'd give me what I was after ie whether JAWS uses this interface to get its info.
I would be grateful if someone could advise me/steer me in the 'right' direction about the way I should be thinking about this.
Visual Basic 6 is unsupported by Microsoft many (12+) years ago. It doesn't have any easy way to incorporate MS Active Accessibility (MSAA), the previous versions were missing support in many of the default graphic widgets, and many controls did and do not have keyboard access.
Don't use it is the best answer, but not to your question. If you must continue, you'll have to look at the MSAA route (you are headed in the right direction with IAccessible interface)
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!
I'm teaching myself (read hacking) through some old Excel Macros that are quite long. However, as I change quite a few lines I want to be sure that I know when and where my new and re-hashed elements are occuring - or not. So my question/s is:
How do I insert a simple message box function that will pop up when a loop/procedure/event has finished?
Add text to it explaining what happened (hard coded ofcourse)?
Also, include an "OK button" that makes it start the next procedure?
The breakpoint process may be the most effective way of doing this, but I would like to use the message box approach so that I can show my colleagues what is happening. Also it would be something that I'd like to incorporate into future projects.
Many thanks for any examples, links or helpful hints.
Michael.
Just use
MsgBox ("message here")
And if you want to go to the code so that you can debug from there on use CTRL + BREAK
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.