I have a TI-Nspire CX. I have some important files on it, which I only need to be able to read (I don't need to edit them for the time being). However, I'm also using my TI-Nspire in my math class and my teacher makes me clear my calculator at the end of the class. Is there any way to archive programs on a TI-Nspire or to make it so that they don't get cleared.
The file is something that was made on a computer (think of it like a program for a game).
Note: You cannot archive programs and files on a TI-Nspire like you do on other calculators.
Disclaimer: The program has nothing to do with the test. In fact, I don't need to access the files until 2 hours after my calculus class but I still need it to be on there for a different class.
If this is impossible, can you explain why?
I suppose that you are typing something in scratchpad's calculator and teacher ask you to clear the history? Firstly, you can save the scratchpad's sessions. Press ctrl+home/file/save and TI will open a new document with your calculator and graph content, which you can save. Then, close the document, go back to scratchpad and clear the history in front of your teacher.
EDIT: after careful reading, it seems i misunderstood the question. What kind of "clear" your teacher wants you to perform, hard reset? Thats a pretty complicated procedure, i really doubt that teacher is that much into TI calcs that she would know it. Please, clarify it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
The question of how blind people program has been answered over and over already, but I couldn't find anything on how being blind and using a screen reader or braille display affects your coding style.
Can you tell code created by blind people apart from other code?
Does being blind cause you to think differently about a problem and look for other solutions?
I'm a blind developer. I will try to answer to your question according to what I do and what I already saw in codes coming form other blind developers.
However, remember that my answer absolutely isn't a reference at all. There are probably as many different usages, habits, preferences as sighted common developers have.
When working in a company and/or for an open source project, we have anyway to format our code as defined by the rules of the given company and/or project. There is no question, it's required.
IN this case me and most of the blind programmers I know of first write unformatted code, compile, test, etc. and only format it when it's time to commit.
Auto-formatting tools as there are in IDE are extremely precious, otherwise it would often be a real pain. If not using an IDE, command-line tools are also common, e.g. astyle for Java and C/C++.
If a given format isn't required by a company and/or project, many of us:
don't indent code, as it usually is more pain to navigate and edit within it, especially if we want to take care of not breaking it. In contrary to sighted people, indentation generally don't help us to quickly identify blocks. Even with a braille display if we have one, we can only see one line at a time.
use other tricks to identify where blocks end, if necessary in case of doubt / when nesting is deep. Most often, this takes the form of a comment following the closing brackets, e.g. } // end for. When the need arrise to do this, it can be a good indicator to tell us that we should better organize the code / better split into different functions.
use a lot of small tricks to be able to jump quickly to a part of code of interest. This can be simple comments like //constructor, which can be immediately be found with Ctrl+F, but it can also be more subtle. For example, one of my personal tricks is to put a space between the name and the open parent when defining or declaring a function, but don't when calling the function. So I can quickly go to the definition (by searching for "name ("), or the places where it is called (by searching for "name(").
hate ASCII art because it's totally useless, ex: a long line of /**********
often use shortcuts to avoid long code that give no real information, e.g. import java.util.* instead of importing 50 classes one by one.
often prefer using simple text editors rather than complex IDE, or only use them for specific functions such as auto-formatting because it's absolutely needed. Two reasons for this: many IDE are unaccessible, only partially accessible, or are mostly accessible but it's not necessary easy or comfortable to use a given feature; or because responsiveness with speech and braille displays is quite poor, i.e. when pressing up/down arrow to read the next/previous line of code, there is a too long delay before it starts speaking (it becomes quickly very annoying, if you multiply 100ms a thousend times).
Well, I answered this question partially here. Basically, you rarely can tell that a piece of code is written by a blind person, unless he/she breaks rules in quite a rude fashion (for example, uses tabs and camelCase instead of spaces and snake_case in Python, like me).
but even those things might be seen only in individual pet projects or quick and dirty scripts. Most of the blind people acknowledge they live in a sighted world, and if you want your pull request to be merged or your code to be reviewed by a superior at work, you must obey the code styling of the project, whether you like it or not, whether you're blind or not. In this situation people at Go made a wise decision to include a formatting utility that every Go developer must run before committing his/her code. "Nobody likes the Gofmt style", says Rob Pike, and he's wrong: I like its style very much: camelCase and tabs, what a delicious thing! But even you don't like it, you must run the tool because it is the language rule to do so.
And to the last part of your question: yes, being blind sometimes makes me to choose a solution, namely a language. As I hate snake_case, I can't think about serious development in Rust, for example, because (again) it's a language rule to write code like this. I do write Python code, but it's... oh well... kind of other thing because Python is so quick and flexible in resolving everyday problems that here I decided to cope with its (annoying) multiple underscores and the absence of block ending markers. BTW, another possible sign of a blind coder is comments like this: } // end if (in something like Javascript or C), or #end if as a whole line in Python. I don't deny sighted people can use those, but if you see every if and for and while ending commented like this, a great chance is that the code was written by a blind person. I personally don't do this, but I know people that like it very much.
I know this question is quite old, but the answer might be relevant still:
I am blind developer and I always intent to follow a coding style of a company or some standard given by developers of a language.
I always indent my code instantly when I write it and screen reader reports the indentation level. Honestly I do not longer have a habit to read unformatted code, but I know blind people who do;
Do the regular docblocking;
Fold/unfold some parts of a code when I need to navigate through large chunks of it;
Regular snakecase / camelcase habit (depends on a language);
Sometimes write longer lines of code and then use IDE to fix the formatting, because it is not always that longer code tends to be more complex for me to read;
Try to enforce myself to restrict the length of a line to be no greater than 80 characters, but it's a bit of a pain to ensure that to happens due to a lack of a good tooling;
Sometimes add some useful comments to help me to debug code (I mean some calculations / formulas in a comments that are not necessary important to others, but it depends).
Personally I found the biggest challenge is to write a code in docblocks (annotations) like in Doctrine or APIPlatform for example, because screen reader reads an indentation to the first non-space / non-tab character in the line which is asterisk (*) in a case of a docblocks.
Not sure how to even search for this topic so I'm just going to ask. I have a couple places in my code where changes to one function have to be also made to a similar function. Basically the operations in the functions are very similar but the data being worked on is different.
I don't like it but for now that's how it is. My question is anyone knows of a way or a tool that will notify me if a certain function has changed. If I get the notification I know to confirm the changes were made to other function.
Please don't tell me to change my code. I know this isn't ideal and thought has been put into alternatives, but nothing elegant has popped up.
Thanks,
Gunner
Here is an idea I have. Maybe it will set the train of thought...
I can add a special comment in my code for a block that I want to be tracked. The comment will have opening and closing syntax:
my_code.php...
//track-start-1234
[CODE]
//track-end-1234
//track-start-5678
[CODE]
//track-end-5678
I will then have a script that I tell to check a list of files, my_code.php, for now. It will look for the special comment syntax. "1234" will represent a file that holds the last modified code for that function, so 1234.php. If the contents between the comments do not match the code stored in the file then an alert is fired. Also I might add a relationship to the other code so the alert says something like
Code 1234 has changed. Please make sure code 5678 has been updated as well.
I think I can add this script to GIT somehow so it either is part of the core git commands like "push" or maybe just another command I have to run as part of our deployment process. A second option might be adding it to phpstorm's code inspector or something like that.
When the code has been modified and everything is good I will just manually copy the new code into the comparison file. There will not be a ton of updates so this will not be too tedious.
For now this is probably the route I'll go, but any critiques or suggestions are definately welcome.
I'm mostly new to programming and so I have come here for some help.
Recently, at work, the program that we have used for years has drastically changed and all of our old file types are no longer supported. This has left us completely out in the cold as to how we can access our old files without using the older software. With that being said, here is my problem with macros that I'm in need of help:
I need to be able to open a file in a specific program, copy all the text in the file, paste the text into a new notepad document and then save the notepad file with file's original name as a simple text document. I need to do this to an entire folder (and eventually folders within a folder but that can wait for now)
If I need to clarify anything let me know. Like I said, I'm new to this stuff and I'd appreciate any tips you guys could give me.
Since you mention Notepad, I'll assume that you are working in Windows. In that case, you're probably best off writing it in PowerScript. I don't have the skills for that, but if you add "Windows" and "PowerScript" to the tags, you may have a better chance of find someone sho does. (You may want to try this question over at SuperUser)
I keep typing "t eh" instead of " the" which is, of course, annoying in the amount of time it takes me to correct myself.
The obvious answer is "Learn to type, noob!" or at least to type more slowly and/or more correctly. This error is frighteningly consistent so it appears I've trained my muscle memory for that pattern already.
But I'm wondering if it's possible to write a small, windows portable script or application that, when it detects the incorrect sequence, backspaces and corrects it automatically at a layer where it would apply to any keyboard input.
Does C# have access to that layer of the OS that intercepts keypresses systemwide?
Will I run into UAC issues with Vista?
Am I re-inventing the wheel (ie, are there open source tools I can modify or use out of the box)?
In DOS this sort of thing was quite easy and one could make TSRs (Terminate and Stay Resident) programs that would, for instance, give you a calculator onscreen with a special keypress. Not to mention the many, many practical joke programs based on this concept (dial "M" for monster!)...
I would, of course, never suggest such a utility could be used that way for co-workers...
-Adam
On windows you could use AutoHotKey. That allows you to create little scripts or macros to automate and correct things like mistypes.
One use was posted on lifehacker which took the common mistyped words and corrected them. It is at http://lifehacker.com/192506/download-of-the-day-universal-autocorrect
UPDATE Per Comment: This is Free software and windows only as far as I know.
The above script is just an example of what it can do. There are a slew of scripts available at AutoHotkeys Site
I suggest AutoHotKey. If you've never used it before, have a quick read of the tutorial: http://www.autohotkey.com/docs/Tutorial.htm
The feature you are looking for is called "hotstrings." http://www.autohotkey.com/docs/Hotstrings.htm
In your case, your script would look something like:
::teh::the
That's it! Add other things you want corrected on additional lines. AutoHotkey scripts can be compiled so you don't have to install AutoHotKey on all of your machines.
It's a very cool program. It's primary use (for making custom hotkeys) rocks! These scripts are system wide so you'll also probably want to make a hotkey to be able to turn them off too!
EDIT: In a comment, it was mentioned that he actually types "t eh" (with a space in it) and I wondered if something additional would be needed for it to work. I just tested it and it works fine. Just install autohotkey, and create a file with the .AHK extension. In that file put in the following line
::t eh::the
and save the file. Then double-click on the AHK file to load AutoHotKey with your script (you'll see a green square in your system tray to let you know it is running). It should work fine!
Yes, you can use pinvoke commands from C# to intercept the low-level os commands. I recommend you take a look at http://www.pinvoke.net. The coding isn't easy but it does work.
I suggest learning to type more slowly. I also suffer from "teh" and "ahve" in part due to autocorrect giving me the leniency. If you forced yourself to retrain then you would not be at a disadvantage when using someone else's machine.
Not to mention the unfortunate event when you need to write "t eh" and are being prevented by an overzealous 'corrector'.
I have the in my opinion odd request to close a wizard form as Done or OK if Enter was pressed on the keyboard even if the OK/DONE button is not focused.
In my opinion that would be a usability mistake. For example: In the wizard you may have multiple controls, buttons, check boxes, multiple line controls and they all have a different behavior on actions from the ENTER key. And don't forget the other buttons in the navigation of the wizard, what if they are focused?
Should these controls don't react on Enter like expected before? Should they do their actions but in other cases where Enter does no further action for the control it should close the form == inconsistent?
I think that is a typical request where the needs of one person would help him but confuse many other.
In my opinion Wizards are very special because they are not only made to make things easier but also very often focus on people with less experience with the functionality of an application. So I take every request serious and try to look into all arguments for and against the request.
Is my point of view to narrow? Are there some usability studies or guidelines especially for Wizards to backup my opinion or maybe proof me wrong?
Thank you very much!
Michael
Well, here's the thing: there are two kinds of users you have to take into account here.
First kind of users are the Baby Boomers and Gen Xers (e.g., people who have been using computers in the 70s/80s) who are accustomed to pressing Enter to move to the next field. These are the ones who learned how to use computers in terminals/consoles and enter means you're finished typing on that field and would move on to the next.
Second kind of users are those who were weaned on Windows. These people are used to pressing the Tab key to move to the next field. Pressing enter to them means they are done with the whole thing.
So which convention should you follow? That will depend on whether you're targetting the first or second type of users, the environment (Windows or Web?), and the OS.
If you're targetting Windows forms, it is much advisable to be consistent to the OS (e.g., letting people use Tab instead of Enter) for form entry. In the web, you're in a quandary, since Enter is trapped by the web browser as a submit event.
In the end the only useful advice I can offer is to try it out with your target customers and see whether they prefer Enter over Tab.
I think the key is to test. You can't really guess what your users will find comfortable, you have to watch them try it. Especially since there are multiple incompatible standards you could follow, you are just going to have to see if this change works for most users in your audience.
I would be of the same opinion, perhaps mention it to the client and let them use the final version in both modes. I guess you have to give them what they ask for when they are paying.
To me this also seems to be an odd request but as Paul says, if the client wants it, then the client gets it.
However from a usability/comprehension standpoint, I would make the border of the ok/done button much thicker then normal so that it stands out a bit and maybe indicate to people that it has special behaviour.
Also I would perhaps make a note in the dialog/wizard box that hitting enter will cause the wizard to close as if the OK/Done button had been pressed.
While the one user may know that hitting enter will close it, unless someone else is specifically told, they will not be expecting that behaviour.
I think you should have a finish page to facilitate this. If the user presses enter by mistake the worst is that he won't finish the wizard, only go to the next page (which may be the finish page). This is good for situations where nuclear bombs are controlled by said wizards.
On the finish page pressing enter would finish the wizard (and blow up Iraq, bring down a satellite, or erase Jimbob's farm).
If the user can re-run the wizard I don't think it would be disasterous if they accidentally finished it.
Remember, wizards should never take any action until they are finished, in case the user cancels or such. Confirmation dialog boxes on a finish are tedious and I will hunt you down if you use them, I think once the user has finished the wizard he is pretty sure about his intent.
Maybe the client has good reasons for it.
Imagine the following situation:
A screen with lots of optional fields that gets opened/closed a lot and where data accuracy is not really critical.
Think of a little program that pops up every half hour to ask you what you have been doing, for what client and maybe some notes so it can gather this info and generate your timesheet.
Being able to open up the screen, enter the info and close it all really quick and with as little hassle as possible is way more important than the accuracy of the data.
I can imagine lots of situations where being able to confirm the field without having focus can be usefull.
Is this request perhaps because the UAT that was undertaken on the wizard involved users that weren't aware that pressing ENTER will have the same effect as clicking the button?
If when the final page of the wizard is displayed, the 'Finish' button is already highlighted (as I would expect) that maybe it's a matter of giving the user some cue that they can also press ENTER at this point.
If you take Google for example, I seem to remember that if you tend to systematically type your search term in and then click the 'Search' button with the mouse, a message is displayed at the top of the search results that kindly hints to you that you can also just press ENTER. Obviously, this is not something that can easily be done in your case because this is the last page of the wizard, but maybe this is the sort of thing that your client is trying to get you to engineer around?
Educate your clients. Show them some documentation as why that suggestion might not be a good usability practice.
Some reputable website will work best, as clients will usually believe a third party before believing you. After all, to them you are probably just being lazy and don't want to work more.
If the client still doesn't concede, then just do what they want, and warn them that it is not the good thing to do.
Although in your case, the "good thing to do" seems a little on the gray area.
I would argue that you could possibly use this functionality to move forward through the wizard but ONLY if no other action had been taken on that page.
The moment a field is completed or a button clicked/highlighted or the cursor is moved from the default position, the Enter functionality should revert to that of the standard OS.
As others have said, clearly this would only work if those using the wizard were made aware of this as part of their application training, but it might prove useful for moving quickly through un-used pages of the wizard to get to where the user needs to be.
Doesn't matter. Choose and be consistant in all your applications