Do you suppose you can write an ActiveX control without Wizard support? I think we all have read Petzold and understand enough of the inner workings of the Windows API to write our own class framework for it or to use your cleaned up version of MFC for it. But ActiveX takes the Baroque period of computer programming into the Roccoco. Most how-to books tell you about IUnknown and after that they are cookbooks into the wizards. Can you (easily) do an ActiveX control without wizard support?
In my best Phil Hartman as Ed McMahon to Dana Carvey's Johnny Carson, you are correct, sir!
I find it interesting that Anders Hejlsberg reverted to wizard-generated code for Visual Studio.NET. I think it is more restrictive than the.DFM model, because with the.DFM model all the object properties are data in the.DFM file, and you (if you know what you are doing!) can override object methods in terms of how stuff is written and read from the.DFM file. If you want to do comparable fancy stuff with.NET (like composite widgets and setting properties of component widgets of composite widgets) you may have to start looking at overriding the classes that control the round trip from Form Designer to code and back (the code DOM classes) and things start to get ugly fast.
Where things start to get code-wizardy is in using Delphi to generate ActiveX controls. You generate an ActiveX control by starting with a VCL control, and then a code wizard spews out tons of stuff. Their model is that they have base classes that handle all the ugly ActiveX stuff, and that you decorate a class derived from such a base class with your own interfaces. They are essentially using the Bridge Design pattern to have your ActiveX object forward all of your interface method calls to a contained VCL control. An ActiveX control is a bridge to a VCL control much as a VCL control is a bridge to a window-handle control.
The wizard takes care of 1) the generation of the ActiveX bridge class code from the ActiveX control, 2) the necessary registration calls to go into your "library" app that compiles to a DLL, and 3) generating the "type library" that exposes your ActiveX control methods and properties to the outside world.
Writing your own VCL control is strictly a matter of inheritance, and any properties you add to the "published" part of a class are exposed to the Form Designer. I think what gums up an ActiveX control is the requirement for maintaining a type library and the requirement that the ActiveX be a bridge to a VCL control. I find it really easy to make changes to a VCL control. Since I don't want to rewizard the ActiveX everytime, I find I have to edit the ActiveX control to keep it in synch with the VCL control. The best way is to use the Type Library Editor, because that allows you to change the ActiveX control interfaces in synch with the IDL code that generates the type library, and once you have updated the ActiveX control interfaces, you can easily write the forwarding code to the corresponding VCL methods.
Can you ditch the wizard and just edit IDL and Delphi code. Good luck! Besides IDL (Interface Design Language -- the C-like code for specifying COM and ActiveX interfaces and properties) being a piece of work in its own right, Delphi imposes its own bizarre (undocumented) restrictions on IDL, and you may as well accept life as it is and make your interface changes through the Type Library Editor.
With practice, I find that I can use the Delphi Type Library Editor to modify and maintain and ActiveX control, and it is reasonably easy to do, but it was far from obvious how this was all supposed to work when I started out, and the documentation or how-to books were far from completely helpful on this score. In other words, in addition to using the wizards to spit out an ActiveX from a VCL as a one-time operation, I can make changes to the VCL and keep the ActiveX in synch with the VCL, only it is a really good idea to make all the ActiveX interface changes through the Type Library Editor, which is a really clunky way of writing code sometimes, but it is the only way to keep the IDL and Delphi code in synch and Delphi happy at the same time.
A genuine troll is where a person puts out a post for the purpose of the controversy it generates. There are a few of us out there who are genuinely confused by Eclipse, and if the Slashdot community wants to dismiss us as trolls, morons, or other unworthies of the programming fraternity, I guess the Eclipse people can have their own little private society. It also seems that Eclipse proponents on Slashdot are a bit thin-skinned regarding any criticism of their beloved product.
Just getting a program to run under Eclipse is a major undertaking. Visual Studio has a "project file" that identifies the void main() (or Java or C# equivalent) for you, so if somebody gives you a VS project as a bundle, you simply load the project file and build and run. I think there is something going on with Eclipse that not only to you have to put files into the project manager, you have to identify the source module containing the program entry point for Run to be able to do something, and it is confusing because Run has a lot of options that a person keeps trying out, but the problem was back in the project manager.
I am sure that once you get the hang of how to use Eclipse it is the Swiss Army Knife of software development, but Eclipse is different, and the state of the examples, docs, and help files is such that it is going to turn away of people who try it out for a casual inspection. So be it. If Eclipse gains mindshare, those of us on the fringes will buckle down and try to learn it, and if Eclipse fades into the background, we will kind of know why it had failed.
The NiMH has its uses, but so does the Alkaline Rechargeable (Rayovac Renewal). Rayovac makes a charger that works with both.
The alkaline starts out at around 1.63 volts and discharges to around.9 volts before it is considered dead. The NiMH is flat at 1.2 volts. For some apps, the NiMH battery comes up "low battery" (like in my friend's pager) because the pager may consider an alkaline discharged to 1.2 volts as about done with. So you have to find out if 1.2 volts per cell will run your appliance.
The other thing about the NiMH is that it self discharges -- it is even worse than the NiCad, only it isn't supposed to have the memory effect that a NiCad has (the camcorder which doesn't fully discharge the NiCad which means the NiCad never ever seems to ever recharge and ever run the camcorder).
Now for the alkaline rechargeable. They say you can put ordinary alkalines in one of those chargers -- tried it and it won't burn the house down, but it won't hold a charge, or it will recharge but have really high internal resistance on discharge. I guess you have to pay for those fancy Renewal batteries if you want to recharge an alkaline.
OK, here's the deal. A fully charged alkaline is over 1.6 volts (none of this 1.2 volt business), and it is supposed to hold its charge forever (I measure.01 volt per day degradation). The rub is that you can't discharge them (ha, ha). What I mean is that if you use them in a flashlight and discharge them until the light gets dim, you have discharged them down to that.9 volt, and you are lucky to get one or maybe two recharges (if that) out of them. The trick is to discharge them only down to 1.5 volts and then freshen 'em up in the charger. Apparently they only like to be discharged a little bit and then recharged as soon as possible -- I use D-cells in a couple of flashlights (a 4-cell Mag and a 2-cell ordinary flashlight). If I use a flashlight on a project (like to change a dead car battery at night, or to poke around a crawlspace, I recharge them as soon as I can). I am told they will live (Rayovac data sheets) nearly forever that way.
Canals being optical illusions, blah, blah. Yes, there was Schaperelli and his "canali", but it was Lowell who really went to town with seeing canals. Do you suppose this was the "cold fusion" of its day? Do you think it is possible, and I don't know how to put this politely, that Lowell just "blew it out his ass?"
It would be one thing if amateur astronomers with good telescopes, good observing sights, and lots of patience saw these canals all the time. It would be like the Face on Mars -- the darned thing does look like a face at low res, and at higher res it breaks up into a bunch of mountains. But I don't think anyone since Lowell has seen any canals, and if it were an optical illusion, they should not be hard to see at all.
You also have to figure on the scientific authority effect. In the public mind, Lowell was a professional astronomer out West someplace with a powerful telescope and dry weather, and if he reported canals, who was to say it ain't so? Nowadays you have all kinds of amateurs with access to all kinds of big telescopes, and if there were anything to it, there would be Sky and Telescope articles on how to observe "the canals of Mars."
There are methods for controlling bugs, but they aren't cheap. Think Space Shuttle flight control software. In terms of number of lines (100,000? in the core modules?) it is not a very big program, but they have spend big bucks studying it and being very conservative about making changes. Oh, and there are only 4 "sites" where it is in operation.
The Microsoft model is that they probably spend less labor on their flagship products than the Shuttle or say the aerospace industry on flight control systems and autopilots. But they sell it to many more people for a much much lower unit cost and rake in the bucks in a way that Rockwell Collins or Sunstrand can only dream. Their big breakthrough business discovery is that they can sell (relatively) cheaply developed software for the desktop, and people are not going to care in a way that counts.
They (NASA and collaborators) tried an ablative coating on one of the 3 X-15 test vehicles. The idea was like to strip and reapply between flights or do some other kind of refurbishment, and it was such a PITA that they gave up on it and went for tiles on the Shuttle.
Maybe the way to go is not to reapply ablative coatings but go for ablative coatings that have a certain number of cycles -- say for a lower temp top surface, the thing has a life of 20 flights and after that you through out the vehicle (NASA is retiring Shuttles after about 25 flights on average, but not in the way they had hoped). For a higher temp leading edge, that may be only good for about 4 flights after which you just replace the entire leading edge panel.
The stylized "G" of the Gnome emblem is viewing the bottom of someone's foot -- the supposed Gnome Creature.
I believe that Middle Eastern culture takes offense at seeing the bottoms of feet -- it is like showing someone your bare ass.
What is so offensive about feet? I think these things are cultural or perhaps species-specific. Why is smiling considered "nice"? That gesture among most primate species is considered a threat (especially a smile that shows teeth).
So what about feet? I think that showing your feet implies a certain degree of undress (you are barefoot in the shower, in the bedroom, in the privacy of your own house, on the beach where you are wearing minimal clothes), even in the let-it-hang-out Western culture. Hippie culture made a big deal about bare feet as a means of iconoclasm, and there is this vogue to show pictures of models and celebs in glossy magazines showing their feet (remember that cover of Time with a barefoot Andreeson and all the letter writers to Time saying he needs to trim is toe nails?).
There is a certain kind of hippie-counter culture aspect to using a G as a stylized foot sole as the Gnome symbol. I am personally a little hung up about feet, and I am bothered by it, but in a way, even if I didn't have a thing about seeing people's feet, it is kind of cutely unprofessional -- I and most other people (except for Middle Easterners who dress their women in tents) don't have anything about faces, but if the Gnome emblem was a Smiley or a scowling or wizened Gnome, we would get tired of that pretty quickly as well.
So why make a big deal about a little icon? I think it speaks to the difference between polished graphics that have appeal to broad segments of the population and ideosynchratic graphics that appeal to some software dude's personal desires, and it speaks to market share. If the Gnome people were serious about gaining more mindshare for Linux on the desktop, they would ditch that foot, and if they are wedded to that foot, they are probably committed to a bunch of other things on principle and will forever stay a tiny slice of the market.
Apologies to Gilbert Godfried
on
Space Blog
·
· Score: 1
My mother always warned me about floating around in space like that because the when you float around like that you get giddy, and when you get giddy the next thing you know you've poked someone's eye out!
Of course GWB had the speech ready if WMD's were used on our troops. What GWB didn't have ready was the speech to use if WMD's were not used on our troops . . . or not encountered by our troops . . . or not found after a couple of months of really hard searching.
Or your could release the source code -- in Pascal. Anyone without enough programming skill to understand your system will rather go blind than read Pascal code.
"But your GUI should be abstracted away in a different component" is like the recipe for elephant stew that reads "First shoot and field dress an elephant . . . "
One kind of abstraction is to separate your program into the "GUI" and "the business rules" and try and put business rules into other objects instead of into customizations of widget classes. Agreed. But there can be a lot of logic associated with the GUI itself -- enabling and graying out menu items depending on what has been selected elsewhere in the GUI, validating edit box fields, and so on. If your GUI is buttons and text boxes that is one thing, but if your GUI is a lot of custom widgets to present graphs that respond to mouse clicks with various kinds of cursors, there is a lot of logic associated with the GUI itself. Try as you may, 60-80 percent of your program modules may contain #include .
Abstraction number two: Model-View-Controller. Instead of a custom widget being one class, it is two classes (Document-View) or three (Model-View-Controller). The Model can obviously be non-GUI, the View is probably GUI, but the Controller could be non-GUI (contain the logic of the widget without reference to a GUI API), but GUI may creep in depending on the signalling and event model.
Abstraction number three: abstract the GUI API into something portable. This is the Java/wxWindows/Eclipse SWT kind of thing. This kind of thing gets into a lot of work because there is a lot to most GUI API's. One approach to try is that you probably don't use the whole GUI API in your application, and you could code your own version of wxWindows/Eclipse SWT that only contains the GUI calls that you actually use. Then you can make your app portable by recoding that layer for different systems. Harder than it looks because you need a good understanding of the abstraction inherent in most GUI API's (I understand the need for the window handle or equivalent in other systems, but I never understood the need for a DC handle (GC handle in SWT, graphics object in.NET) -- why can't you just draw stuff to the window? Also why does Borland call the DC a "canvas" because the DC is not a canvas in the sense of a framebuffer and if you want a framebuffer for your widget you have to go through a whole bunch of rigamarole creating a bitmap object and then getting a DC/GC/Canvas for the bitmap object so you can actually draw to it and then you have to get the DC/GC/Canvas for your windows so you can blit your framebuffer bitmap to it only if you are in a Paint method of your main window you have to use the DC/GC/Canvas given to you.
Making your program easier to port by separating GUI from non-GUI is a good idea, but it is far from an easy thing to do in many cases. The OO programming principle that an object should not be called procedurally but should have verbs that it knows how to carry out has the effect of tying a lot of logic into GUI object classes.
Apart from vanilla buttons and edit box GUI's (like a Farenheit to Celsius calculator), there are no simple answers to portability of GUI's.
Attending graduate school at a certain institution of higher learning in Greater Los Angeles with (at the time) a particularly poor male-female ratio (for a male), I decided to invest the time, money, and energy learning ice dancing as a way of to meet women and as a distraction from studies. As an engineering student, the detailed lessons in the management of kinetic energy required to skate with a partner in close formation were something I could learn quickly. You may not think of ice dancing as a geek thing, but we had more than one NASA/JPL person in the group. At the time (20 years ago) there were 3 evenings a week where large numbers of people get together to do this in Burbank and one afternoon on the weekend where this happened in Santa Monica.
Ice dancing is a lot like ballroom dancing on skates inasmuch as its done with male-female partners, the steps are to the beat of the music, and the dance holds (waltz, tango) are much like ballroom only you are going much faster and the forces are much higher and you are wearing edged instruments that can draw blood on your feet, so the holds are somewhat modified and the partners are farther apart.
Unlike ballroom, when ice dancing is done socially the skaters follow very rigidly choreographed steps that weave in and out along arcs called lobes that fill up the entire skating rink to make up what is called a pattern. The need for this strict choreography will be apparent. When the music is announced, couples line up to start the pattern, the initiation of which takes place on the musical downbeat for each couple at the head of the line. To allow as many couples to participate, each new couple at the head of the line needs to launch with the downbeat of each successive measure of the song. You will observe that the couples back in line will start rocking in synchrony with the music so they are able to launch without hestitation when their downbeat occurs.
I find it interesting to watch individual pairs of skaters who are really good, such as in competitions and the Olympics, but I also like to watch a rink full of social skaters, no individual couple being Olympic quality, but with the skaters stroking and turning across the ice in time with the music, it all looks like a magical merry-go-round.
You know what they say about auto racing -- the spectators are not there to see them race. The really fun part to watch is when a skater trips and brings his or her partner down in a clattering heap (I've wrecked hundreds of times -- it hurts but you keep doing it) -- you then see this choreographed dance come apart as skaters dodge and weave, and sometimes you have a multi-couple pile up as if it were a pileup on I-5.
OK, watching people get hurt is not funny unless it is America's Funniest Home Videos where taking hits to the groin is the only joke. But ice dancing spills are part of the sport just like checking is part of hockey and driving too close to the edge and losing your car on the wall is part of auto racing, and you need to see one of these ice dancing pileups before you get too enthusiastic about high-speed belt-type people mover systems.
The point of this is that with the proper training, you can get large formations of people moving at high speed together like a well-regulated machine, but it takes just one person to trip. Do they have pileups like this in bike races?
Troll? What are the moderators smoking? The discussion is about China entering space, largely for the same reasons as the U.S. and the old S.S.S.R. (USSR) entered space, for reasons of national prestige and demonstration of superpower status. Carbon Unit offered an explanation why the U.S. went to the Moon and then stopped when it got there.
My take is that the space race wasn't about the development of ICBMs because the ICBM programs had separate funding and organizations. The space race was about the Cold War demonstration of ICBM technology: multi-stage rockets, gyro guidance, computer controls.
In discussions of Hiroshima, it was argued that the US shouldn't have bombed civilians but should have bombed a remote island to which we invited the Japanese generals -- a "demonstration" of the Bomb would have forced surrender. Now one can argue whether a demonstration would have had the same effect as the actual bombing or perhaps the opposite effect in warning Japan to evacuate cities and fight on or whatever. But a demonstration was very much part of the tactics of the Cold War. Russian military representatives were invited to observe Crossroads Able (the Bikini Atol bomb test of a Hiroshima-yield bomb -- it didn't awe Stalin as much as would have hoped while it motivated Stalin to get his own Bomb. It also gave a certain French bathing suit style its name: Bikini -- the story I read in the old Saturday Evening Post was that in the 50's with people living under the threat of the Bomb and Soviet Union Cold War adversary, those bathing suits were popular at pool-side party where such daring wear was motivated by, "What the heck, the world is going to end anyway." Also, Crossroads Able is THE atom bomb shot you see in all those film clips of Bomb tests -- the way it sent a shock wave racing across the water looks really cool.)
I agree that the space race was the demonstration, not of the Bomb but of the Bomb delivery system. Once the US got to the Moon, there was not much more to demonstrate and hence the space program lost its impetus.
Cooper in "About Face" where he talks about his likes and dislikes complains about too many popups and alerts. Many of the alerts are for things like "Do you really want to formant Drive C:?" where they are supposed to save you from disaster while in Windows XP when I select Start (yeah, I know) followed by Shut Down it gives me a really annoying dialog box (I told you to shut down and now you are asking again -- actually the same sequence is in Windows 98, but somehow it seems less annoying because it is worded differently).
Cooper's idea is that you should economize on alert boxes and confirmations because the break the user's work flow. I guess the reason we hate Clippy is that it keeps interrupting and distracting when we don't need help.
I am in to saving electricity in the house, for my own satisfaction and to show people that they are writing checks to the power company without giving it much thought. The biggest saving is not to leave stuff on all the time, and I am not going to leave a 60 W box plus a 30 W flat screen on all the time.
I understand hibernation to be as you say, off - no CPU, no RAM, no hard disk. The only "on" thing is the couple of watts required to keep a PCI motherboard plugged in. What I want hibernation for is to have FAX/answering machine on all the time and only use a couple of standby watts to do this. Of course the thing has to unhibernate before enough rings go by that the caller gives up.
I have never been successful getting hibernate to work. I am currently using an ASUS TUSL-2C and what I had before that was one or other VIA offering (Intel PCI boards both of them). It is always something stupid, like the thing unhibernates and the mouse freezes up (that is on the ASUS, on the VIA I don't even get that far).
Are there lists of hardware that people know about where they got hibernate to work? I am not even sure if I can get recent desktop Dells to hibernate.
Anyway, the point of this is that it is not design, not UI whatever, it is that the features that are announced (like ACPI hibernate) just don't work. People need to wring the bugs out of the technology before talking about fancy interface stuff they want. Or rather I would like to see a lot more bugs getting the technology to work rather than ignoring that and coming out with more Windows versions.
My best example of a technology challenge is getting graphics files, and especially Windows metafiles to interoperate (with just about anything else), but that's a whole other story.
Yeah, and burning coal is solar energy because it is the stored up energy from fossil plants (unless you believe Thomas Gold about elemental carbon and planet formation).
And I am a vegetarian for eating steaks because cows store up the food energy of grass.
The violence of war is ultimately about the effect on people's minds -- war is rarely fought to the point of utter annihilation, so the point is to use violent or coercive means to convince the other side they are beaten.
Conventional war, whether it is applied to military or civilian targets, means to do just that. Terrorist war is an indirect approach. The idea is that you don't have enough strength to wage conventional war, but you have enough capability to inflict enough damage on the other side to provoke a violent response, and that retaliation against your own side serves as a recruiting tool for your guerrilla militia or to harden the resolve of your civilians to perservere.
By my definition, the Israelis are terrorists, and they are much better terrorists than Arafat and company.
The Israelis may have the military power, but they lack to alliances, political support, and other factors to wage conventional war on their Fatah, Hizbollah, Hamas, and their backers. So they conduct raids where they assissinate Palestinian generals. Note that when Palestinian civilians get killed as "collatoral" damage it is not that big of a deal, but when one of these generals gets killed, the Palestinian suicide-bomber machine gets into high gear. Now what do the Palestinians do with their limited amount of explosives? Do they ambush Israeli tanks in the fashion of the Chechens (they have tried it, but either the Israeli military is too good or they have not stuck with it)? No, they go and attack Israeli civilians.
Are these attacks on Israeli civilians putting pressure on Israel to sue for peace? Quite the opposite -- they are silencing any opposition to the Sharon government -- the attacks are what elected the Sharon government.
The Israelis were losing big time in the First Intifada where the TV images of soldiers shooting and rock-throwing crowds made them look like the old South African regime. The Israelis are winning in this Intifada because they are able to serve up their own civilians as victims -- Churchill won the Battle Britain when he got the Germans to stop bombing airfields and radar stations and to dump their bombs on central London. And Palestinian leaders are too dumb or too undisciplined to know what is going on.
9-11 was a one-time thing in that now that people are wise to the tactic, it won't ever work again -- witness "shoe-bomber" Richard Reid and how he was waylaid by other passengers.
Does this mean now that the kind of hijacker who simply wants to go to Cuba or collect a ransom or something is S.O.L. for all time? Have any "conventional" hijackings been attempted since?
Why when I was your age, weeee didn't have those fancy-shmancy C++ compilers, IDE's, and PC's, we wrote out COBOL longhand and then typed the programs in ourselves using keypunch machines until our fingers bled, and we liked it!
It is all a matter of what a person was trained on: I can whip out Pascal code a lot faster than C++ (all that keypunch practice means I can type out begin and end faster than you can select Shift and hunt for curly braces). Delphi Object Pascal is so extended from ANSI Pascal (string handling, C-style pointer/array syntax) that it is for the most part line-by-line mappable between C++ and back. And if you complain that Delphi lacks your favorite C++ features (templates, stack-allocated object instances, STL), lets just say C# is pretty much Delphi-with-C-syntax when you really look at it carefully, and C# has never evoked the opinion that it was particularly difficult to program in by C/C++ programmers.
This business about how nightly builds are the only proper coding model and that anyone cycling through compile-link-run is hacking -- while I guess all the advocates of interactive/interpreted languages ranging from Lisp to BASIC to Perl to Python are all hackers. The Delphi compiler is that fast that it has many of the advantages of the interactive/interpreted languages while having compiled-language execution speed. There were people who once thought that time-sharing was bunk because if someone was too sloppy to use keypunch and batch runs, they were probably writing hacked up code.
As to putting the brakes on language features to trade off for speed being stupid, it is only slow for you because you are used to prefix instead of postfix type declarations and don't have begin and end under your fingers. The opposite extreme of giving language features free reign and compiler considerations be damned is called Ada . . .
Delphi components points out one of the hangups of third party approaches.
An ActiveX component is pretty much an ActiveX component (and yes, I have used Delphi to produce and consume them). Say what you will about Microsoft, but they try not to break their own stuff, and you can develop an ActiveX under Windows 95 and use it under Windows XP.
A VCL component in many ways is better than an ActiveX -- it is a class, not a walled-off COM component, so you can extend it with inheritance. In addition, you can link it up to other components by setting property values to point to other VCL components in the Object Inspector (you can link up ActiveX components, but you have to do it programmatically at run time). This linking up of components is not perhaps as widely used as it could, in part because you have to override the virtual Notification method to handle the connection and disconnection of components without crashing your component in the Designer, but the capability is there and is very useful.
Where VCL components become a PITA is that they are specific to Delphi version. You either tell people that your components only work with Delphi 7 and when Delphi 8 comes out they have to upgrade your component, or you have to have a collection of old Delphi's to come up with versions of your components for, say, Delphi's 3-7.
Also, ActiveX components have a simple deployment process -- one or more.OCX files and invoke regsvr32 if you want to install them by hand. I write my Delphi stuff using a separate.pas file for each class when this is practical, so any VCL component I generate has a wad of.DCU files that need to be distributed. There is probably a way to wad the.DCU files together that you can tell me about, but you know what I am talking about.
Anders Hejlsberg and Microsoft teamed up to try to get this right with.NET assemblies. An assembly is a.DLL file like and OCX, you can wad up an entire class framework in a single assembly, and you have the option of installing an assembly globaly or only using it privately one application at a time. Oh, and you can extend classes from inside an assembly by proper OO inheritance, and.NET components can be hooked up to other.NET components by setting properties to component references in the Designer just like with the VCL.
Trouble is.NET is kind of slow in being pushed out to end users -- even if you buy a computer with XP installed, you have to install the.NET runtime separately. While the transition to Windows 95 API was a "big bang" in that Microsoft really pushed the upgrade to consumers and for developers to target the Win32 API, the transition to.NET is being pursued rather cautiously, and Microsoft doesn't seem to be pushing.NET as a platform for shrink-wrapped software at least quite yet.
I remember talking to an IBM dude who lectured at the university about how they built one of their mid-range systems as a byte-code interpreter layered on top of a Power PC chip and how OO figured prominently in the effort.
I complained to him about OO, specifically about the clunkiness of massive GUI frameworks such as VCL and MFC. Since then I have been on a little friendlier terms with VCL, but it is still a massive wad that bloats programs, but hey, memory is cheap. He sympathized with my take on reuse issues of general-purpose massive application frameworks, but argued that for in-house projects at IBM, the reuse can be strong.
A programmer can develop good reuse of their own stuff in their own projects, a small group can do some reuse depending on how well they document and communicate, and working the way up the chain the reuse may be more limited.
Clement Szyperski has a good discussion in Component Software on the dream of widespread reuse and some of the obstacles to achieving it. Following his discussion, the best success of top-level (commercial, between organizations) reuse is at the operating system level (who anymore tries to roll their own window manager as in the days when we tried to write GUI programs in DOS). The next level is in terms of language features, libraries, and stuff like the STL. The level after that is third party components, of which he mentions that Visual Basic has developed a market but few other systems have succeeded at the level of widespread sale of software components.
So we are making some progress towards software reuse, using OO and other techniques, but the progress is slow in coming because people are still figuring out what works, but we are getting there.
Slashdot Mirror
Do you suppose you can write an ActiveX control without Wizard support? I think we all have read Petzold and understand enough of the inner workings of the Windows API to write our own class framework for it or to use your cleaned up version of MFC for it. But ActiveX takes the Baroque period of computer programming into the Roccoco. Most how-to books tell you about IUnknown and after that they are cookbooks into the wizards. Can you (easily) do an ActiveX control without wizard support?
I find it interesting that Anders Hejlsberg reverted to wizard-generated code for Visual Studio .NET. I think it is more restrictive than the .DFM model, because with the .DFM model all the object properties are data in the .DFM file, and you (if you know what you are doing!) can override object methods in terms of how stuff is written and read from the .DFM file. If you want to do comparable fancy stuff with .NET (like composite widgets and setting properties of component widgets of composite widgets) you may have to start looking at overriding the classes that control the round trip from Form Designer to code and back (the code DOM classes) and things start to get ugly fast.
Where things start to get code-wizardy is in using Delphi to generate ActiveX controls. You generate an ActiveX control by starting with a VCL control, and then a code wizard spews out tons of stuff. Their model is that they have base classes that handle all the ugly ActiveX stuff, and that you decorate a class derived from such a base class with your own interfaces. They are essentially using the Bridge Design pattern to have your ActiveX object forward all of your interface method calls to a contained VCL control. An ActiveX control is a bridge to a VCL control much as a VCL control is a bridge to a window-handle control.
The wizard takes care of 1) the generation of the ActiveX bridge class code from the ActiveX control, 2) the necessary registration calls to go into your "library" app that compiles to a DLL, and 3) generating the "type library" that exposes your ActiveX control methods and properties to the outside world.
Writing your own VCL control is strictly a matter of inheritance, and any properties you add to the "published" part of a class are exposed to the Form Designer. I think what gums up an ActiveX control is the requirement for maintaining a type library and the requirement that the ActiveX be a bridge to a VCL control. I find it really easy to make changes to a VCL control. Since I don't want to rewizard the ActiveX everytime, I find I have to edit the ActiveX control to keep it in synch with the VCL control. The best way is to use the Type Library Editor, because that allows you to change the ActiveX control interfaces in synch with the IDL code that generates the type library, and once you have updated the ActiveX control interfaces, you can easily write the forwarding code to the corresponding VCL methods.
Can you ditch the wizard and just edit IDL and Delphi code. Good luck! Besides IDL (Interface Design Language -- the C-like code for specifying COM and ActiveX interfaces and properties) being a piece of work in its own right, Delphi imposes its own bizarre (undocumented) restrictions on IDL, and you may as well accept life as it is and make your interface changes through the Type Library Editor.
With practice, I find that I can use the Delphi Type Library Editor to modify and maintain and ActiveX control, and it is reasonably easy to do, but it was far from obvious how this was all supposed to work when I started out, and the documentation or how-to books were far from completely helpful on this score. In other words, in addition to using the wizards to spit out an ActiveX from a VCL as a one-time operation, I can make changes to the VCL and keep the ActiveX in synch with the VCL, only it is a really good idea to make all the ActiveX interface changes through the Type Library Editor, which is a really clunky way of writing code sometimes, but it is the only way to keep the IDL and Delphi code in synch and Delphi happy at the same time.
Just getting a program to run under Eclipse is a major undertaking. Visual Studio has a "project file" that identifies the void main() (or Java or C# equivalent) for you, so if somebody gives you a VS project as a bundle, you simply load the project file and build and run. I think there is something going on with Eclipse that not only to you have to put files into the project manager, you have to identify the source module containing the program entry point for Run to be able to do something, and it is confusing because Run has a lot of options that a person keeps trying out, but the problem was back in the project manager.
I am sure that once you get the hang of how to use Eclipse it is the Swiss Army Knife of software development, but Eclipse is different, and the state of the examples, docs, and help files is such that it is going to turn away of people who try it out for a casual inspection. So be it. If Eclipse gains mindshare, those of us on the fringes will buckle down and try to learn it, and if Eclipse fades into the background, we will kind of know why it had failed.
The alkaline starts out at around 1.63 volts and discharges to around .9 volts before it is considered dead. The NiMH is flat at 1.2 volts. For some apps, the NiMH battery comes up "low battery" (like in my friend's pager) because the pager may consider an alkaline discharged to 1.2 volts as about done with. So you have to find out if 1.2 volts per cell will run your appliance.
The other thing about the NiMH is that it self discharges -- it is even worse than the NiCad, only it isn't supposed to have the memory effect that a NiCad has (the camcorder which doesn't fully discharge the NiCad which means the NiCad never ever seems to ever recharge and ever run the camcorder).
Now for the alkaline rechargeable. They say you can put ordinary alkalines in one of those chargers -- tried it and it won't burn the house down, but it won't hold a charge, or it will recharge but have really high internal resistance on discharge. I guess you have to pay for those fancy Renewal batteries if you want to recharge an alkaline.
OK, here's the deal. A fully charged alkaline is over 1.6 volts (none of this 1.2 volt business), and it is supposed to hold its charge forever (I measure .01 volt per day degradation). The rub is that you can't discharge them (ha, ha). What I mean is that if you use them in a flashlight and discharge them until the light gets dim, you have discharged them down to that .9 volt, and you are lucky to get one or maybe two recharges (if that) out of them. The trick is to discharge them only down to 1.5 volts and then freshen 'em up in the charger. Apparently they only like to be discharged a little bit and then recharged as soon as possible -- I use D-cells in a couple of flashlights (a 4-cell Mag and a 2-cell ordinary flashlight). If I use a flashlight on a project (like to change a dead car battery at night, or to poke around a crawlspace, I recharge them as soon as I can). I am told they will live (Rayovac data sheets) nearly forever that way.
It would be one thing if amateur astronomers with good telescopes, good observing sights, and lots of patience saw these canals all the time. It would be like the Face on Mars -- the darned thing does look like a face at low res, and at higher res it breaks up into a bunch of mountains. But I don't think anyone since Lowell has seen any canals, and if it were an optical illusion, they should not be hard to see at all.
You also have to figure on the scientific authority effect. In the public mind, Lowell was a professional astronomer out West someplace with a powerful telescope and dry weather, and if he reported canals, who was to say it ain't so? Nowadays you have all kinds of amateurs with access to all kinds of big telescopes, and if there were anything to it, there would be Sky and Telescope articles on how to observe "the canals of Mars."
There are methods for controlling bugs, but they aren't cheap. Think Space Shuttle flight control software. In terms of number of lines (100,000? in the core modules?) it is not a very big program, but they have spend big bucks studying it and being very conservative about making changes. Oh, and there are only 4 "sites" where it is in operation. The Microsoft model is that they probably spend less labor on their flagship products than the Shuttle or say the aerospace industry on flight control systems and autopilots. But they sell it to many more people for a much much lower unit cost and rake in the bucks in a way that Rockwell Collins or Sunstrand can only dream. Their big breakthrough business discovery is that they can sell (relatively) cheaply developed software for the desktop, and people are not going to care in a way that counts.
Maybe the way to go is not to reapply ablative coatings but go for ablative coatings that have a certain number of cycles -- say for a lower temp top surface, the thing has a life of 20 flights and after that you through out the vehicle (NASA is retiring Shuttles after about 25 flights on average, but not in the way they had hoped). For a higher temp leading edge, that may be only good for about 4 flights after which you just replace the entire leading edge panel.
I believe that Middle Eastern culture takes offense at seeing the bottoms of feet -- it is like showing someone your bare ass.
What is so offensive about feet? I think these things are cultural or perhaps species-specific. Why is smiling considered "nice"? That gesture among most primate species is considered a threat (especially a smile that shows teeth).
So what about feet? I think that showing your feet implies a certain degree of undress (you are barefoot in the shower, in the bedroom, in the privacy of your own house, on the beach where you are wearing minimal clothes), even in the let-it-hang-out Western culture. Hippie culture made a big deal about bare feet as a means of iconoclasm, and there is this vogue to show pictures of models and celebs in glossy magazines showing their feet (remember that cover of Time with a barefoot Andreeson and all the letter writers to Time saying he needs to trim is toe nails?).
There is a certain kind of hippie-counter culture aspect to using a G as a stylized foot sole as the Gnome symbol. I am personally a little hung up about feet, and I am bothered by it, but in a way, even if I didn't have a thing about seeing people's feet, it is kind of cutely unprofessional -- I and most other people (except for Middle Easterners who dress their women in tents) don't have anything about faces, but if the Gnome emblem was a Smiley or a scowling or wizened Gnome, we would get tired of that pretty quickly as well.
So why make a big deal about a little icon? I think it speaks to the difference between polished graphics that have appeal to broad segments of the population and ideosynchratic graphics that appeal to some software dude's personal desires, and it speaks to market share. If the Gnome people were serious about gaining more mindshare for Linux on the desktop, they would ditch that foot, and if they are wedded to that foot, they are probably committed to a bunch of other things on principle and will forever stay a tiny slice of the market.
My mother always warned me about floating around in space like that because the when you float around like that you get giddy, and when you get giddy the next thing you know you've poked someone's eye out!
Of course GWB had the speech ready if WMD's were used on our troops. What GWB didn't have ready was the speech to use if WMD's were not used on our troops . . . or not encountered by our troops . . . or not found after a couple of months of really hard searching.
Or your could release the source code -- in Pascal. Anyone without enough programming skill to understand your system will rather go blind than read Pascal code.
So this means that attempts to figure out to program to any of a number of Windows API's are not DCMA circumvention violations?
And with the 4.7 Gig of the DvD burner already available, why are we messing with such stuff?
One kind of abstraction is to separate your program into the "GUI" and "the business rules" and try and put business rules into other objects instead of into customizations of widget classes. Agreed. But there can be a lot of logic associated with the GUI itself -- enabling and graying out menu items depending on what has been selected elsewhere in the GUI, validating edit box fields, and so on. If your GUI is buttons and text boxes that is one thing, but if your GUI is a lot of custom widgets to present graphs that respond to mouse clicks with various kinds of cursors, there is a lot of logic associated with the GUI itself. Try as you may, 60-80 percent of your program modules may contain #include .
Abstraction number two: Model-View-Controller. Instead of a custom widget being one class, it is two classes (Document-View) or three (Model-View-Controller). The Model can obviously be non-GUI, the View is probably GUI, but the Controller could be non-GUI (contain the logic of the widget without reference to a GUI API), but GUI may creep in depending on the signalling and event model.
Abstraction number three: abstract the GUI API into something portable. This is the Java/wxWindows/Eclipse SWT kind of thing. This kind of thing gets into a lot of work because there is a lot to most GUI API's. One approach to try is that you probably don't use the whole GUI API in your application, and you could code your own version of wxWindows/Eclipse SWT that only contains the GUI calls that you actually use. Then you can make your app portable by recoding that layer for different systems. Harder than it looks because you need a good understanding of the abstraction inherent in most GUI API's (I understand the need for the window handle or equivalent in other systems, but I never understood the need for a DC handle (GC handle in SWT, graphics object in .NET) -- why can't you just draw stuff to the window? Also why does Borland call the DC a "canvas" because the DC is not a canvas in the sense of a framebuffer and if you want a framebuffer for your widget you have to go through a whole bunch of rigamarole creating a bitmap object and then getting a DC/GC/Canvas for the bitmap object so you can actually draw to it and then you have to get the DC/GC/Canvas for your windows so you can blit your framebuffer bitmap to it only if you are in a Paint method of your main window you have to use the DC/GC/Canvas given to you.
Making your program easier to port by separating GUI from non-GUI is a good idea, but it is far from an easy thing to do in many cases. The OO programming principle that an object should not be called procedurally but should have verbs that it knows how to carry out has the effect of tying a lot of logic into GUI object classes.
Apart from vanilla buttons and edit box GUI's (like a Farenheit to Celsius calculator), there are no simple answers to portability of GUI's.
Ice dancing is a lot like ballroom dancing on skates inasmuch as its done with male-female partners, the steps are to the beat of the music, and the dance holds (waltz, tango) are much like ballroom only you are going much faster and the forces are much higher and you are wearing edged instruments that can draw blood on your feet, so the holds are somewhat modified and the partners are farther apart.
Unlike ballroom, when ice dancing is done socially the skaters follow very rigidly choreographed steps that weave in and out along arcs called lobes that fill up the entire skating rink to make up what is called a pattern. The need for this strict choreography will be apparent. When the music is announced, couples line up to start the pattern, the initiation of which takes place on the musical downbeat for each couple at the head of the line. To allow as many couples to participate, each new couple at the head of the line needs to launch with the downbeat of each successive measure of the song. You will observe that the couples back in line will start rocking in synchrony with the music so they are able to launch without hestitation when their downbeat occurs.
I find it interesting to watch individual pairs of skaters who are really good, such as in competitions and the Olympics, but I also like to watch a rink full of social skaters, no individual couple being Olympic quality, but with the skaters stroking and turning across the ice in time with the music, it all looks like a magical merry-go-round.
You know what they say about auto racing -- the spectators are not there to see them race. The really fun part to watch is when a skater trips and brings his or her partner down in a clattering heap (I've wrecked hundreds of times -- it hurts but you keep doing it) -- you then see this choreographed dance come apart as skaters dodge and weave, and sometimes you have a multi-couple pile up as if it were a pileup on I-5.
OK, watching people get hurt is not funny unless it is America's Funniest Home Videos where taking hits to the groin is the only joke. But ice dancing spills are part of the sport just like checking is part of hockey and driving too close to the edge and losing your car on the wall is part of auto racing, and you need to see one of these ice dancing pileups before you get too enthusiastic about high-speed belt-type people mover systems.
The point of this is that with the proper training, you can get large formations of people moving at high speed together like a well-regulated machine, but it takes just one person to trip. Do they have pileups like this in bike races?
My take is that the space race wasn't about the development of ICBMs because the ICBM programs had separate funding and organizations. The space race was about the Cold War demonstration of ICBM technology: multi-stage rockets, gyro guidance, computer controls.
In discussions of Hiroshima, it was argued that the US shouldn't have bombed civilians but should have bombed a remote island to which we invited the Japanese generals -- a "demonstration" of the Bomb would have forced surrender. Now one can argue whether a demonstration would have had the same effect as the actual bombing or perhaps the opposite effect in warning Japan to evacuate cities and fight on or whatever. But a demonstration was very much part of the tactics of the Cold War. Russian military representatives were invited to observe Crossroads Able (the Bikini Atol bomb test of a Hiroshima-yield bomb -- it didn't awe Stalin as much as would have hoped while it motivated Stalin to get his own Bomb. It also gave a certain French bathing suit style its name: Bikini -- the story I read in the old Saturday Evening Post was that in the 50's with people living under the threat of the Bomb and Soviet Union Cold War adversary, those bathing suits were popular at pool-side party where such daring wear was motivated by, "What the heck, the world is going to end anyway." Also, Crossroads Able is THE atom bomb shot you see in all those film clips of Bomb tests -- the way it sent a shock wave racing across the water looks really cool.)
I agree that the space race was the demonstration, not of the Bomb but of the Bomb delivery system. Once the US got to the Moon, there was not much more to demonstrate and hence the space program lost its impetus.
Cooper's idea is that you should economize on alert boxes and confirmations because the break the user's work flow. I guess the reason we hate Clippy is that it keeps interrupting and distracting when we don't need help.
If I recall, the 9-11 dudes were all up in First/Business class. And OBL himself seems to be pretty wealthy.
I understand hibernation to be as you say, off - no CPU, no RAM, no hard disk. The only "on" thing is the couple of watts required to keep a PCI motherboard plugged in. What I want hibernation for is to have FAX/answering machine on all the time and only use a couple of standby watts to do this. Of course the thing has to unhibernate before enough rings go by that the caller gives up.
I have never been successful getting hibernate to work. I am currently using an ASUS TUSL-2C and what I had before that was one or other VIA offering (Intel PCI boards both of them). It is always something stupid, like the thing unhibernates and the mouse freezes up (that is on the ASUS, on the VIA I don't even get that far).
Are there lists of hardware that people know about where they got hibernate to work? I am not even sure if I can get recent desktop Dells to hibernate.
Anyway, the point of this is that it is not design, not UI whatever, it is that the features that are announced (like ACPI hibernate) just don't work. People need to wring the bugs out of the technology before talking about fancy interface stuff they want. Or rather I would like to see a lot more bugs getting the technology to work rather than ignoring that and coming out with more Windows versions.
My best example of a technology challenge is getting graphics files, and especially Windows metafiles to interoperate (with just about anything else), but that's a whole other story.
And I am a vegetarian for eating steaks because cows store up the food energy of grass.
Conventional war, whether it is applied to military or civilian targets, means to do just that. Terrorist war is an indirect approach. The idea is that you don't have enough strength to wage conventional war, but you have enough capability to inflict enough damage on the other side to provoke a violent response, and that retaliation against your own side serves as a recruiting tool for your guerrilla militia or to harden the resolve of your civilians to perservere.
By my definition, the Israelis are terrorists, and they are much better terrorists than Arafat and company.
The Israelis may have the military power, but they lack to alliances, political support, and other factors to wage conventional war on their Fatah, Hizbollah, Hamas, and their backers. So they conduct raids where they assissinate Palestinian generals. Note that when Palestinian civilians get killed as "collatoral" damage it is not that big of a deal, but when one of these generals gets killed, the Palestinian suicide-bomber machine gets into high gear. Now what do the Palestinians do with their limited amount of explosives? Do they ambush Israeli tanks in the fashion of the Chechens (they have tried it, but either the Israeli military is too good or they have not stuck with it)? No, they go and attack Israeli civilians.
Are these attacks on Israeli civilians putting pressure on Israel to sue for peace? Quite the opposite -- they are silencing any opposition to the Sharon government -- the attacks are what elected the Sharon government.
The Israelis were losing big time in the First Intifada where the TV images of soldiers shooting and rock-throwing crowds made them look like the old South African regime. The Israelis are winning in this Intifada because they are able to serve up their own civilians as victims -- Churchill won the Battle Britain when he got the Germans to stop bombing airfields and radar stations and to dump their bombs on central London. And Palestinian leaders are too dumb or too undisciplined to know what is going on.
Does this mean now that the kind of hijacker who simply wants to go to Cuba or collect a ransom or something is S.O.L. for all time? Have any "conventional" hijackings been attempted since?
It is all a matter of what a person was trained on: I can whip out Pascal code a lot faster than C++ (all that keypunch practice means I can type out begin and end faster than you can select Shift and hunt for curly braces). Delphi Object Pascal is so extended from ANSI Pascal (string handling, C-style pointer/array syntax) that it is for the most part line-by-line mappable between C++ and back. And if you complain that Delphi lacks your favorite C++ features (templates, stack-allocated object instances, STL), lets just say C# is pretty much Delphi-with-C-syntax when you really look at it carefully, and C# has never evoked the opinion that it was particularly difficult to program in by C/C++ programmers.
This business about how nightly builds are the only proper coding model and that anyone cycling through compile-link-run is hacking -- while I guess all the advocates of interactive/interpreted languages ranging from Lisp to BASIC to Perl to Python are all hackers. The Delphi compiler is that fast that it has many of the advantages of the interactive/interpreted languages while having compiled-language execution speed. There were people who once thought that time-sharing was bunk because if someone was too sloppy to use keypunch and batch runs, they were probably writing hacked up code.
As to putting the brakes on language features to trade off for speed being stupid, it is only slow for you because you are used to prefix instead of postfix type declarations and don't have begin and end under your fingers. The opposite extreme of giving language features free reign and compiler considerations be damned is called Ada . . .
An ActiveX component is pretty much an ActiveX component (and yes, I have used Delphi to produce and consume them). Say what you will about Microsoft, but they try not to break their own stuff, and you can develop an ActiveX under Windows 95 and use it under Windows XP.
A VCL component in many ways is better than an ActiveX -- it is a class, not a walled-off COM component, so you can extend it with inheritance. In addition, you can link it up to other components by setting property values to point to other VCL components in the Object Inspector (you can link up ActiveX components, but you have to do it programmatically at run time). This linking up of components is not perhaps as widely used as it could, in part because you have to override the virtual Notification method to handle the connection and disconnection of components without crashing your component in the Designer, but the capability is there and is very useful.
Where VCL components become a PITA is that they are specific to Delphi version. You either tell people that your components only work with Delphi 7 and when Delphi 8 comes out they have to upgrade your component, or you have to have a collection of old Delphi's to come up with versions of your components for, say, Delphi's 3-7.
Also, ActiveX components have a simple deployment process -- one or more .OCX files and invoke regsvr32 if you want to install them by hand. I write my Delphi stuff using a separate .pas file for each class when this is practical, so any VCL component I generate has a wad of .DCU files that need to be distributed. There is probably a way to wad the .DCU files together that you can tell me about, but you know what I am talking about.
Anders Hejlsberg and Microsoft teamed up to try to get this right with .NET assemblies. An assembly is a .DLL file like and OCX, you can wad up an entire class framework in a single assembly, and you have the option of installing an assembly globaly or only using it privately one application at a time. Oh, and you can extend classes from inside an assembly by proper OO inheritance, and .NET components can be hooked up to other .NET components by setting properties to component references in the Designer just like with the VCL.
Trouble is .NET is kind of slow in being pushed out to end users -- even if you buy a computer with XP installed, you have to install the .NET runtime separately. While the transition to Windows 95 API was a "big bang" in that Microsoft really pushed the upgrade to consumers and for developers to target the Win32 API, the transition to .NET is being pursued rather cautiously, and Microsoft doesn't seem to be pushing .NET as a platform for shrink-wrapped software at least quite yet.
I complained to him about OO, specifically about the clunkiness of massive GUI frameworks such as VCL and MFC. Since then I have been on a little friendlier terms with VCL, but it is still a massive wad that bloats programs, but hey, memory is cheap. He sympathized with my take on reuse issues of general-purpose massive application frameworks, but argued that for in-house projects at IBM, the reuse can be strong.
A programmer can develop good reuse of their own stuff in their own projects, a small group can do some reuse depending on how well they document and communicate, and working the way up the chain the reuse may be more limited.
Clement Szyperski has a good discussion in Component Software on the dream of widespread reuse and some of the obstacles to achieving it. Following his discussion, the best success of top-level (commercial, between organizations) reuse is at the operating system level (who anymore tries to roll their own window manager as in the days when we tried to write GUI programs in DOS). The next level is in terms of language features, libraries, and stuff like the STL. The level after that is third party components, of which he mentions that Visual Basic has developed a market but few other systems have succeeded at the level of widespread sale of software components.
So we are making some progress towards software reuse, using OO and other techniques, but the progress is slow in coming because people are still figuring out what works, but we are getting there.