Is there a command to reset all variables to 0 and clean all textfields?
Like, if you go in the iOS-Simulator, then iOS-Simulator up in the Menu -> Clear Preferences and Contents (or something like this... in german: Inhalte und Einstellungen zurücksetzen).
That would be much easier to reset all data instead of setting all variables manually to 0.
If I understand the context of your question correctly, NO there is no command to reset all the variables of your currently visible user interface in the simulator to zero and/or blank.
Think about it -- the simulator would need to know some intimate details about the guts of your application, details that are probably only available only at compile time.
If you want to clear our variables or text fields or whatever, it would be smarter to have a UIButton in your interface available temporarily (for debugging purposes only, if you want) that would do what you want to do while you are testing things out.
Related
I know how to use the Xcode debugger, and I've used po to display values for variables.
The problem I'm having is that I want to see the variable values, and track how multiple variables change (when stepping through the code) and have these values displayed in the debugger window, without having to write "po ..." every time!
Is there a way to do that? I mean, how do xCoders simultaneously see 10-15 variables change as a consequence of stepping over a function?
And thanks for all your answers, this thing has been driving me crazy for quite a while!
First read the documentation (Section Debug Area Help).
In the variables view (in debug area) you can track when the values change. The changed variables are marked in blue. In addition you can watch the variables.
I have a simple form (NSWindow) with 3 text fields. NSWindow's initialFirstResponder is 'pointing' to the first field (NSTextField). All three text fields are circularly linked to each other via nextKeyView.
Problem that I have is that when I start the application from Xcode it'll focus on the text field that was last active (in focus) when the application closed.
So for example, if I name text fields A, B and C and initialFirstResponder is set to A. Now if I start the application, focus on B, and close the application, next time I start it, the focus will be on B.
Why is that and how would I fix this?
(Sorry if this is a trivial question, these are my first steps in cocoa...)
EDIT:
This is on OS X Lion 10.7.1, Xcode 4.1.
EDIT 2:
I found a way to "fix" this... In the main window (or any window for that matter) XIB/NIB file, click on "Attributes Inspector", then uncheck "Restorable" box. Now the application will not store the last position and so the initialFirstResponder seeing will be respected and followed accordingly.
Welcome to Cocoa! :) I suspect this is happening as part of the new user interface preservation features in OS X Lion. (In fact, I just created a simple app with 3 text fields, and I see this behavior too.) Because windows automatically restore themselves, you will see a lot of this behavior happening automatically even if you didn't implement it. This is probably desirable — most applications will work this way, and the user will come to expect it.
However, if you really want to disable it, you can probably do so by subclassing NSWindow or perhaps NSTextField and overriding -encodeRestorableStateWithCoder:. But, I definitely recommend you leave the default behavior alone.
Edit with a little further information: the app state seems to be stored in ~/Library/Saved Application State/com.yourapp.savedState. There you can see a plist file with information about the windows. The other files don't seem easily readable, but they probably contain information about which field is first responder, etc.
Despite this thread being almost 10 years old I'll gonna add an answer. Just about one month after the answer from jbandes OS X 10.7 Lion was introduced.
Following a quote from NSWindowRestoration.h
#interface NSWindow (NSUserInterfaceRestoration)
/* Determines whether the window should be restored on relaunch. By default, windows with NSTitledWindowMask set in the styleMask are restorable, and windows without it set are not.
*/
#property (getter=isRestorable) BOOL restorable API_AVAILABLE(macos(10.7));
I am making a program called "BasicSys". It is a BASIC System simulator that uses a textbox for the console. So far I have everything working great but I need to have the text box act like a command prompt window. It needs to be able to ask for input and retreive the value without allowing the user to modify anything outside of the prompt space (the space where the user should only be able to type is after a ":" or a ">"). Some feilds are password feilds that require either no echoing or having the chartacters replaced by *'s. Is it possible to make a console out of a textbox?
P.S. I also want to know if there are any small BASIC v2 compilers for Win32 so BasicSys can compile and run BASIC programs.
Depending on how realistic you want it to be you can use the API to open a real console window and interact with it. There are many examples available that you can find by searching such as this one. My suggestion though would be to fake it with a multi-line textbox. It would not be very tricky. Set an index every time you draw the prompt, then as long as the cursor is positioned after the index the textbox is read / write. If the user scrolls backwards make the textbox read only. It should be fairly simple using the KeyDown event and setting the ReadOnly property True / False to get a passable "command" window.
I'm having a bit of a strange issue that I can't quite figure out. I'm somewhat of a n00b to Interface Builder. What I am trying to do seems like it should be simple, but it's not working for some reason.
In interface builder I have a preferences window with a simple NSTextField. I have set the value binding to the Shared User Defaults Controller with the controller key "values" and model key "test". I build/run my app and open the preferences window, type some random value into said text field, close the window. Command-Q the app. Then in a shell i do a "defaults read com.xxx.yyy" for my app and the key and value are nowhere to be found. That being said, it seems like the next time I fire up the app and change the value it works but only if I switch focus off of the NSTextField before closing the window.
In the documentation for NSUserDefaults it says that the shared controller saves values immediately, am I missing something stupid here?
Thanks for any help.
I'm answering this a long time after it was asked in case others find it useful.
It sounds like you need to set "Continuously Updates Values" for the text field you've bound. Otherwise, the value is only sent and, accordingly, the preferences only updated when something happens to 'finalise' the edit. That's usually triggered by pressing Return and probably also happens when you switch focus away from the window (though I just tested this in one of my own applications and it didn't seem to commit the edit).
Inital Problem: to have no scattered windows when I use vspilt in Vim inside Screen
Attemps to solve the problem:
Impossible: to increase the Display Refreshing Rate for Mac's terminal code
to add something to .Xresources
alt text http://dl.getdropbox.com/u/175564/bugWithScreen.png
Unix Power Tools -book says that the problem can be solved in .Xresources.
However, it does not specify exacly how.
I have collected the following codes to my .Xresources
mrxvt*scrollBar: true
mrxvt*loginShell: true
mrxvt*syncTabTitle: true
mrxvt*font: Monaco
mrxvt*faceSize: 11
mrxvt*xft: True
mrxvt*xftFont: Monaco
mrxvt*xftSize: 12
mrxvt*xftAntialias: True
mrxvt*termName: xterm-256color
XTerm*VT100.metaSendsEscape: True
# translations used to coordinate xterm with xcilpboard
# Unix Power Tools: p.117
*VT100.Translations: #override\
Button1 <Btn3Down>: select-end(primary,CUT_BUFFER0,CLIPBOARD)\n\
!Shift <Btn2Up>: insert-selection(CLIPBOARD)\n\
~Shift ~Ctrl ~Meta <Btn2Up>: insert-selection(primary,CUT_BUFFER0)
Is this occurring when you run Tlist, or when reconnecting to a previously opened session?
If it's the latter (and your window size varies), it may be because of the options screen was launched with. Try launching screen with these options "-aADR". "-a" and "-A" will force screen to redraw upon reconnection.
Parsing of ~/.Xresources is done when the X11 server is started, as part of the X11 session init scripts. If you edit ~/.Xresources then you need to use xrdb(1) to load in the new file to tell the running X11 server about the changes.
BEWARE that xrdb(1) will, by default, replace the current resources instead of overwriting them and read from stdin is the default, so don't invoke it with no parameters! So you want to use
xrdb -merge ~/.Xresources
to load the changed file in. You can use
xrdb -query
to see what's already loaded.
For the Mac, I don't know what, where or when, might be looking at ~/.Xresources; because the X11 stuff is a program run to use the display, rather than the master of everything graphical, it might be rather minimal and not doing so by default. xrdb -query will help.
One thing that might help is to instead set XAPPLRESDIR as an exported shell variable; there's some knob somewhere in MacOS to set environment variables as a session thing, visible to all programs without hitting the user shell, but I forget where (found it when setting up the SSH Keychain once). XAPPLRESDIR is an env variable variable to point to a user's own overrides of application resources. It's value should be a directory ($HOME/share/xapps/ for instance). Every X11 application linked against the X Intrinsics library (libXt) will, at X11 init time, look in that directory for files matching the application class name. This way, you don't need to worry about loading resources, etc; edit the app file, start the program.
So resources for xterm go into a file XTerm, etc; to find out the class of an arbitrary program, you might use xprop(1) with no arguments, click in the target window while the pointer is a cross-hair and then look at stdout from xprop for the WM_CLASS property. For some older tools like xterm you can also use editres(1) to be able to interactively view the widgets of a running X application via remote inspection; there's a Get Tree menu item, to let you click on the target app and another menu item to show the class names.
Myself, my ~/share/xapps/XTerm file sets the menu background colour to a hideous yellow; that way, when I control-<left|middle|right>-click in an XTerm I immediately know if something is wrong and my resources weren't loaded.
#ifdef COLOR
XTerm.SimpleMenu*background: yellow
#endif