My calculator project, again.

I just got back my 7 segment LED circuit boards from Pad2Pad, and hooked one up, and connected it to my HC08 for testing. The way this works is that the processor only needs to drive 4 lines: data, shift, load into display and reset. My test software program runs a 16-bit counter (of which we only see 12 bits), displaying the bottom three digits as hex as it counts upwards.

And here are the results:

Flawless! The circuit worked without any problems or needing any line cuts or jumpers. Hopefully I’ll have a chance to wire up three of these and hook it up to my calculator software soon…

Okay, Google: what were you thinking?!?

To my fuzzy little brain, the core of a ‘view’ object, be it an NSView, a JComponent, or a HWND object is simple: it’s a rectangular piece of screen real estate. It can draw into its piece of screen real estate. It gets called when it needs to be redrawn and when it is optionally clicked on. It gets called when its location inside the superview is changed. And it can have the ‘keyboard focus’ (whatever the hell you want to call that), so that keystrokes and menu commands are routed to it. And ideally it is embedded in a hierarchy of other views, and has a well designed event subsystem which allows unhandled events to be forwarded to the appropriate parent view or to other event handler abstractions in the system.

So to my fuzzy little brain, the Google Android OS should, when the aspect ratio of the screen is changed by opening the keyboard, send some sort of ‘size changed’ message. And perhaps as part of the message I can either just resize my children or, in a dramatic (but unlikely) case tear down and rebuild my contents–such as having a list view turn into a map view.

So when I read the following here:

Unless you specify otherwise, a configuration change (such as a change in screen orientation, language, input devices, etc) will cause your current activity to be destroyed, going through the normal activity lifecycle process of onPause(), onStop(), and onDestroy() as appropriate. If the activity had been in the foreground or visible to the user, once onDestroy() is called in that instance then a new instance of the activity will be created, with whatever savedInstanceState the previous instance had generated from onSaveInstanceState(Bundle).

This is done because any application resource, including layout files, can change based on any configuration value. Thus the only safe way to handle a configuration change is to re-retrieve all resources, including layouts, drawables, and strings. Because activities must already know how to save their state and re-create themselves from that state, this is a convenient way to have an activity restart itself with a new configuration.

(Emphasis mine.)

WT(bloody)F?!?

My calculator project

I figured a steampunk calculator would be made using a number of modules that are handcrafted from smaller components–so I just designed a circuit board which can drive 3 7-segment LEDs using a shift register circuit, and ordered 12 of the circuit boards from Pad2Pad. They’re 1.5 inches wide by 2.5 inches tall, and hold 3 LED segments; my calculator will then contain 3 of these for a 9 digit display: 6 digits to the left of the decimal point and 3 digits to the right, but with only 2 on by default. The beauty of the design is that I only need 4 control pins total: clear, shift, load and data, and I can drive the entire 9 digit display.

I also ordered a SP4T switch which I plan to use to switch between the four operators (+/-/×/÷), and a key switch to turn the calculator on and off. I also ordered C-cell holders for the 3v power supply. And a whole bunch of buttons for the calculator face.

Once I have the boards I can start testing the calculator code. In the meantime, when I have free time I intend to get the Java emulator of the HC08 working.