[Looking for Charlie's main web site?]

Got a modern Dell laptop? You may have a built in hot-spot finder you didn't know about

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
You know how sometimes you're traveling with your laptop and wonder if you might have a wireless network available? Wouldn't it be nice to detect that without having to turn on your laptop? Well, there are certainly devices you can buy (hotspot finders) which can help you identify when your near a hotspot, but I just learned of a feature built into my Dell Latitude D620 (and which is in others like the D420 and 820, and some XPZ units).

Called the "wi-fi catcher", it's that switch on the left side (on my unit), which I knew could be used to turn the wireless adapter off or on. But if you pull it toward you, that enables this "wi-fi catcher".

Cooler still, and to the point above, it turns out that this feature works even when the laptop is turned off (or in standby or hibernate). One thing, though: you need to enabled this feature using the Dell QuickSet mechanism (one of your icons in the system tray).

You can learn more about the wi-fi catcher, in this case about the d620, at:

https://support.dell.com/support/edocs/systems/latd620/en/UG/wireless.htm#wp1138019

Here's a screenshot of the switch:

And an explanation of that screenshot is here, including an explanation of the colors you'll see and what they mean.

Finally, I'll point that I first read of this feature myself at this review:

http://www.notebookreview.com/default.asp?newsID=2846&laptop=Dell+Latitude+D620+Review

Sure, we should all read our owner's manuals, but at a minimum, sometimes you learn more from someone's distilled review. :-)

Did you know you can store CFDOCUMENT and CFREPORT output in a variable?

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
This may not be news to some, but it was to me. I just noticed that the CF7 tag, CFDOCUMENT (as well as the new form of CFREPORT), has an available NAME attribute. This allows you to save the resulting PDF or FlashPaper (or Excel, in the case of CFREPORT) output (in binary form) to a variable.

Some may know the available FileName attribute, which allows you to save the output to a file. This NAME attribute is simply an interesting alternative.

Here's a quick example:

<cfdocument format="PDF" name="test">
test
</cfdocument>

This creates a variable named test. How would you output it? CFCONTENT, of course, with the appropriate content type. If your page has created any other output, don't forget the Reset attribute as well:

<cfcontent variable="#test#" type="application/pdf" reset="Yes">

To output a Flashpaper format report, use a CFCONTENT type of "application/x-shockwave-flash", and for a CFREPORT Excel spreadsheet, use a CFCONTENT type of "application/vnd.ms-excel".

Why might you do this?

Of course, if you just did that above, you might as well not have bothered, right? The point is that you may do something between when you create the variable and when you output it. For one thing, you may create it in one CFC, custom tag, or CFFUNCTION-based UDF and then output it later in the request.

More likely, you may choose this approach to facilitate caching and later reusing the generated output. Just as with creating a variable with any tag, you could have instead provided a prefix scope like session, application, or server. Then you could manage that cached result any of the many ways that have long existed for caching other tag results in shared scope variables.

Posting a form to itself without trickery, using an empty ACTION attribute

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Did you know that if a form has an empty ACTION attribute (or none at all), it will post back to itself (to the page that presented the form)? This can be very useful, and it's a lot easier than more complicated code that struggles to build the ACTION attribute to hold the current filename and any query string.

In the first iteration of this entry, I referred to the two approaches of either providing an empty ACTION or none at all, but as the comments below show, the former violates the HTML spec. So let's stick with the notion of an empty ACTION. Same result, though.

How often have we all seen code along the lines of:

<form action="<cfoutput>#cgi.script_name#?#cgi.query_string#</cfoutput>" method="post">
...

or more involved:

<cfset action=CGI.SCRIPT_NAME>
<cfif CGI.QUERY_STRING NEQ "">
   <cfset action=action & "?" & xmlformat(CGI.QUERY_STRING)>
</cfif>
<form action="<cfoutput>#action#</cfoutput>" method="post">
...

All this could be replaced very simply with:

<form method="post" action="">
...

The form will post back to itself. I'll offer another post that shows a unique way to take advantage of this. In any case, I hope that this observation may help some folks.

(Update: I never got around to that other entry in 2007, but see a my reply to a comment below where someone asked for more info on the idea I had in mind.

Is this reliable?

Now, there are some who will argue that this is a violation of the HTTP HTML spec, and so it may be, but I've never found a browser in which it didn't work.

Again, a clarification over what I wrote originallyhere. As was refined in the comments below, it's a violation to have *no* ACTION, but it's perfectly legit according to the URI spec (section 4.2 at http://www.ietf.org/rfc/rfc2396.txt) to have an empty ACTION, which is interpreted as a "same-document reference. (Thanks, Christopher Bradford, for that info.) Given that, even the following cautions seem needless, but I'll leave them for any still concerned.

If you have any hesitation, because you have to support multiple browsers and you can't test all possibilities, I'll understand if you choose to pass on this. But certainly if you only need to support browsers you can test, then if it works as expected, enjoy.

If anyone reading this can offer where this is the case, I'd appreciate hearing it. If you want some simple code to test, try this:

<form method="post" action="">
   <input type="Submit">
</form>
<cfif cgi.request_method is "post">
   Posted to itself
</cfif>

If it shows the text within the IF, then it worked as expected.

What about query string info?

You may wonder about the earlier more involved examples that showed passing the query string, in case any had been passed to the form. No problem. This technique passes any query string along just fine. Try it yourself (add ?test=test to the form and view in the debugging info that it's still in the URL scope after submission.)

Copyright ©2019 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting