Tone's Notes

The following tips are from a FAQ found here:

One of the most common and vexing problems with water-based products are the air bubbles, or air entrapment. Any fast-drying product tends to have problems with air bubbles, but air bubbles are more inherent to water-based products because of the way they interact with the pores of the wood, literally forcing air/gas to escape. Allowing or causing the finish to dry too fast or allowing air movement during the initial drying process is the most common cause of air bubbles--the finish just does not have enough time to flow and level before it sets up. The following are a few time-honored “air bubble” remedies that I have compiled from my experiences and others..

1. Prevent drafts or moving air during wet film setup, at least until the finish has leveled out. In the case of water-based finishes, give it an hour and then ventilate the work area.
2. Control your Air temp & Humidity. Follow the manufacturer's recommendations.
3. Experiment with different film thicknesses.
4. Do not sand with stearated sand paper and make sure the surface is properly prepared.
5. Experiment with your spray gun settings.
6. Don't use HVLP turbine type spraying units, as they tend to warm the air and cause the finish to dry too quickly. Use HVLP conversion guns, or conventional sprayers
7. Depending on the product, thin the finish with water--start at 10% and add more if needed. Some products suggest you use their retarder. Best to follow manufacturer recommendations.
8. Lightly dampen the surface, with a sponge or a water bottle sprayer. The water will travel through the film keeping it wet longer, so the bubbles have more time to break.
9. If you are brushing, do not use a sponge or foam brushes, do not shake the finish, and properly prepare the surface. If the grain raises, it will cause a rough surface that will cause air bubbles as you pass your brush over the rough surface.

From Steve Mickley:

“Stearated sandpaper contains something called Zinc Stearates in its coating to make sanding easier by preventing "clogging". Zinc Stearate is a soap like material that is also used in many "sanding sealers" for much the same purpose - a benefit of dubious value given the alternatives available and the potential downside. The problem is that it is quite soft, not at all moisture resistant, and can cause adhesion problems in incompatible finishes. As a result, whether in the form of sanding sealer left behind under your topcoat, or in the form of a film left on the surface after sanding, this stuff can cause problems. While there are many who would argue this point, I feel about Stearates in the shop much the same as I do about silicones; I don't want them anywhere in the building.”

Photoshop’s Actions support creating sequences of commands to be repeated. By placing prompts in the action some simple forms of input can be provided. Actions are basically good only for repeating a sequence of commands. They also support creating droplets.

A Photoshop Droplet is a small executable that supports dragging and dropping of sets of files and folders. A Droplet is always tied to a single Action. The Action is performed for each file in the drop set.

JavaScript allows nearly complete automation of the Photoshop CS application.

I was looking for a way to save all the images in a folder under the same name but with LZW Tiff compression. An Action alone couldn’t do it because the SaveAs dialog insists on binding a specific folder to the operation. A complex script could have done the job except I’d end up writing a lot of file and folder manipulation code.

The answer is to write a very simple script that saves the current document as LZW Tiff under the current documents name. Then create an action out of the script and finally a droplet out of the action.

Here’s the script:

if (app.documents.length == 0) {

    alert("No active document to save.");

} else {

    var doc = app.activeDocument;

    var opts = new TiffSaveOptions();

    opts.imageCompression = TIFFEncoding.TIFFLZW;

    doc.saveAs(doc.fullName, opts);

}

Now I have a “Tif Compress.exe” droplet that I can just drag and drop a set of files and folders on which will save all the files in the set using the LZW Tiff format.

If you’ve been frustrated by Whidbey’s Windows Forms support for application settings management here’s a tip that may help you.

There are two major bits of functionality involved. The first is the support for reading and writing the xml configuration files for both user and application settings. The second is the support for creating Binding objects to tie the settings properties to various object properties in your application.

The Binding stuff is much more broken than the xml read/write stuff.

My suggestion is to not use the “Application Settings” on the Property panel. It invariably shoots me in the foot, scrambling the *.Designer.cs files with random settings getting stuck where they don’t belong.

Instead, take charge of manually transferring the properties to and from the Properties.Settings.Value object. Right after InitializeComponent(), copy them out, and right before Properties.Settings.Value.Save() copy them back.

All the truly mysterious behavior of when user config files were and were not written, as well as random changes to the applications UI, disappeared after I eliminated all the automatically generated Binding objects.

I did try manually creating the Bindings, but the bugs seem to be inherent in the code that identifies actual object fields to update based on the state of the Binding objects. It seems to just get it wrong with painful regularity.

It is just beta code after all J

Here’s an MSDN article that I found useful. Specifically, it answered why some settings are read-only wile others are read-write. Obvious once you think about it!

I’m looking forward to when it all works smoothly…

this.button1.DataBindings.Add(new System.Windows.Forms.Binding("Font", SettingsTest.Properties.Settings.Value, "ButtonFont", true, "", null, System.Windows.Forms.BindingUpdateMode.OnPropertyChanged));

I’ve seen a number of developers surprised by InvokeRequired returning false in situations when they know it’s a cross thread call.

The reason is that the underlying window handle associated with the control has not been created yet at the time of the call.

Since InvokeRequired is meant to be used with either BeginInvoke or just Invoke, and neither of these methods can succeed until a windows message pump gets associated with the control, it elects to return false.

There is some support for FTP in Whidbey beta 1, but it still failed my real world requirements.

Using both the FtpWebRequest / FtpWebResponse and WebClient classes failed to connect to an embedded system running an ftp server that Windows Explorer had no trouble connecting to.

I tried two third party FTP components for .NET (Mabry's FTP/NET and CSpot’s FTPComponent). Both components succeeded in connecting to the server when run as Visual Studio 2003 projects (using their own sample code). But both components failed (typically by hanging in the class constructors) when run after conversion to Visual Studio 2005 (Whidbey beta 1).

It seems that at the moment, there’s just enough FTP implementation in Whidbey to work with some FTP servers, but not all, and just enough changes to interfere with the existing crop of 3^rd party components.