robobait

Archived Posts from this Category

Where to find Report Properties and PageSize Properties (Report Builder 3.0, SQL Server Reporting Services 2012)

Posted by Jim DeLaHunt on 30 Nov 2012 | Tagged as: robobait

This is a simple tip, but one which uncovers that which Microsoft’s Report Builder 3.0 hides in plain sight. It took me forever to figure out. Here are some screen shots, so that web searchers of the future won’t have to take so long.

Report Builder 3.0 is an application which lets you design reports for use with Microsoft’s SQL Server Reporting Services 2012 (SSRS). One of my clients has me using SSRS to generate reports, which are formatted as PDF files. Obviously this requires a pagination process: laying out report content into PDF pages of specified sizes, and keeping specified margins of blank space around the page’s edge.

I discovered that SSRS defaults to using 1″ margins around a Letter-sized page (8.5″ x 11″). I wanted to change that, to make the margins smaller, and to let me use more of the page. SSRS has pretty good documentation, including a helpful MSDN article Pagination in Reporting Services (Report Builder and SSRS). This article advises,

“By default, the page size is 8.5 x 11 inches but you can change this size by using the Report Properties, Page Setup dialog box or by changing the PageHeight and PageWidth properties in the Properties pane….  Margins are specified using the Report Properties, Page Setup dialog box or by changing the TopMargin, BottomMargin, LeftMargin and RightMargin properties in the Properties pane.”

SSRS ReportBuilder report body properties (medium)

Great! I clearly wanted to find the TopMargin and BottomMargin properties in the Properties pane. I could see the Properties pane easily (see the first screen shot, click for a full-sized rendition). But I couldn’t find any PageSize or Margin properties. Next, I looked for a way to bring up the Report Properties dialog box. I expected this to be on the Tools or Format or File menu of a Windows app. But Report Builder 3.0 is built with a new UI design, which lacked the traditional Windows menu bar.

So, for a long time I was stuck. I couldn’t find how to make report-level properties like PageSize or Margin appear in the Properties pane. And I couldn’t find the Report Properties dialog box. Nor could I find documentation on how to do these things, just documentation that assumed I could do it.  I was stuck for a couple of weeks, living with unsatisfactory margins, and getting other things done. Until I discovered the trick.

Simply put, the trick is to click outside the report body. The second screen shot adds annotations, showing important parts of the Report Builder 3.0 window.

SSRS ReportBuilder PageSize, Margin properties annotated (medium)

  • A is the report body, an obvious place to click, and not helpful for finding Report Properties and PageSize properties.
  • B is the design surface outside the report body; left-click here and report-level parameters like PageSize and Margins appear in…
  • the Properties Pane, marked as C.
  • D shows the pop-up menu which appears when you right-click on the design surface; select Report Properties… from this menu to bring up the Report Properties dialog box.

I achieved my goal, making the report margins smaller, by clicking at B. The Margins parameter set appeared in the Properties pane. From there, it was easy to adjust the value of the Top and Bottom Margins parameters.

And now I’ve published this robobait, in hopes of seeding search engines with notes of this trick, and helping others get unstuck faster.  Please let me know in the comments if this was useful.

Daytime running lights in a US Mazda 3: lessons learned

Posted by Jim DeLaHunt on 30 Sep 2012 | Tagged as: Canada, robobait

We recently imported our 2005 Mazda 3, built to California standards, into Canada. As part of that, we had to convert it to have daytime running lights — the headlights needed to stay on anytime the car is running. Why? Safety, it is said; a waste of fuel, it is also said; but the main thing is that C.R.C. c. 1038 Schedule IV Standard 108 requires it, and so we did it. It was almost, but not quite, a simple matter of installing a $40 aftermarket controller module (Hamsar 70987) Detail of Hamsar 70987 controllerbought from Canadian Tire.  Here’s the lessons we learned that weren’t in the instructions. I hope they will help others installing daytime running lights in a Mazda 3.

1. Getting physical access to the headlight wiring is hard. The module requires one wire each to be attached to the active (+) wire of the low-beam lights, high-beam lights, and turn signal lights. These lights are, on the left side, hidden under a (removable) battery compartment vent, plus various framework pieces of the engine mounting and body front. Attaching the module wire to the existing headlight wire isn’t hard; the kit includes splice taps which makes the wire splicing a simple matter of placing wires and squeezing with pliers. But physically reaching the existing wires, between and behind all that structure, was hard.

2. Mazda 3 access through wheel wellThe trick to reaching the turn signal lights is to go up from below, through the front wheel well.  The turn signal lights are nestled under a particularly thick tangle of structural members. I thought I would have to take off the headlight assembly to reach the turn signal light wiring. But no; I found a posting on reparing tail lights which explained the brilliant idea of coming up from below. I turned the steering wheel to the left, moving the forward edge of the left front wheel out of the way and opening room in the wheel well. Then I unscrewed the two screws holding the front edge of the (plastic, flexible) wheel well guard to the car body.  This allowed me to pull back the wheel well guard, reach my hand up between the guard and the body, and reach the wire harness at the back of the turn signal light without too much difficulty.

3. Wrapping the green activation wire around spark plug wires was insufficientMazda 3 spark plug wires don’t reliably trigger this module; you need to attach the wire to a wire with a reliable voltage which turns on only when the car is running. The place to find such a wire is in the wiring patch panel in the middle of the fuze box. The module has  a green wire, which controls the module. Put a voltage on this wire (relative to auto-body ground) and the module turns on the headlights. Remove the voltage, and after a few seconds, the headlights go off. The kit suggests wrapping the wire around the spark plug wire, and securing with cable ties. I suppose the idea is that the sparking voltage down the wire will induce a voltage in the wire. I tried this; the result was headlights which were on most of the time, but sagged off during deceleration. This rig failed the import inspection — twice.

Note that Mazda 3 spark plugs are wired with two small-gauge conductors, not one thick conductor. I suspect the electrical properties of the Mazda 3 spark plug wires aren’t what the module required. In any case, the green wire, wrapped around the spark plug wires, wasn’t adequate.

I was not up for determining which wire in the engine had the right voltage at the right time. So I gave up and went to a mechanic. The mechanic, having done a couple hundred such installations, had no trouble finding a wire in the patch panel which had a dependable voltage. Thus, the lights became reliable.

I hope these notes and photos will help other Mazda 3 owners who need to install aftermarket daytime running lights.

Eclipse + Mac OS X 10.5.8 + Java SE 6 => 64 bits

Posted by Jim DeLaHunt on 31 Aug 2012 | Tagged as: robobait, software engineering

I recently had an adventure trying to get a plugin, PDT, installed into my Eclipse software development environment. Diagnosis was hard, and the conclusion was non-obvious, though in hindsight, reasonable. It is that if you want to use an Eclipse plug-in that requires Java SE 6 on a Mac OS X 10.5.8 computer, you will need the 64-bit version of Eclipse.

Let me explain.

Continue Reading »

Canada Post and USPS rate cards

Posted by Jim DeLaHunt on 31 Jul 2012 | Tagged as: Canada, USA, robobait

Canada Post and the US Postal Service raised their postage rates in January, and I’ve just got around to updating my handy Canada Post and USPS postage rate quick reference card on this blog. The Canada Post rate increases were effective January 16, 2012, and the USPS increases were effective January 22.

My Canada Post and USPS Postage Rates project page,  http://jdlh.com/en/pr/postage_card.html, will have links to download the latest charts as I update them.  The spreadsheet source file for the charts is also there. Both are licensed CC-BY-SA, so please feel free to re-use and modify them (as long as you attribute my work and share your product as freely).

Heads up: Canada Post has already received approval for first-class mail rate increases in 2013 and 2014. Both Canada Post and USPS offer “perpetual” or “forever” stamps, which are worth first-class basic domestic postage, whatever the price may increase to.

Enjoy!

Ads Factory “GoogleX, GoogleY” means (lat, long) not (horizontal, vertical)

Posted by Jim DeLaHunt on 30 Jun 2011 | Tagged as: CMS, Joomla, robobait, software engineering, web technology

I want to pass along a tip about confusing field names used in the Ads Factory component for Joomla for geographic data.  I encountered this while customising this component for a client. At first I thought it was a bug, but now I think it’s just an odd naming convention.

Ads Factory, by Romanian developers The Factory,  is a commercial component for Joomla 1.5 which lets you add classified ads to your Joomla site. (My client had me working with version 1.x on Joomla 1.5, but I see there is also a version 2.1 of Ads Factory which is Joomla 1.6 native.) There are quite a few places where Ads Factory includes geographic information: each user record can record a latitude and longitude for that user; each ad can record a latitude and longitude for the advertised merchandise; and there is way to make a “radius search”, i.e. find all ads within a given distance of a user-specified location.

These latitude and longitude values are stored in database fields with name suffixes “X” and “Y”. The user’s latitude and longitude are stored in fields “GoogleX” and “GoogleY” of the Ads Factory user table. Similarly, but not completely consistently, the ad’s latitude and longitude are stored in fields “MapX” and “MapY” of the Ads Factory ads table. The confusion comes in understanding which field stores the latitude, and which stores the longitude.

Latitude is, of course, the signed number of degrees north of the equator of a point on the earth’s surface. It ranges from +90.0 (the North Pole) to 0.0 (the Equator) to -90.0 (the South Pole). Thus, it’s a vertical coordinate. Longitude is the signed number of degrees east of the 0° meridian (roughly Greenwich, England). It ranges from +180.0 to -180.0. My part of North America is 122-123° west of Greenwich, so we have longitudes of -123.0 to -122.0 or so. It’s a horizontal coordinate. This is a well-established convention in many mapping standards.

Tidy Cartesian mathematicians like me use the convention of (X,Y) coordinates, where X is the horizontal coordinate and Y is the vertical coordinate. This is a well-established convention in geometry and graphics (though there are some exceptions).

My first interpretation of Ads Factory field names like  “GoogleX” and “GoogleY” was to interpret them according to the Cartesian convention: X is horizontal, and so stores longitude, while Y is vertical, and so stores latitude. Thus (MapX, MapY) would be (longitude, latitude), the opposite of what one expects from mapping. Odd. I was surprised to find some parts of the code storing latitude in X (the horizontal coordinate!) and longitude in Y (the vertical!), which was surely a bug. I was horrified when it appeared that every part of this code had the same bug!

Then I understood the convention. Ads Factory’s developer appear to have used the (X, Y) convention to indicate just the order of the coordinates, but not their Cartesian meaning.  (MapX, MapY) means (latitude, longitude), as is conventional in mapping.  X is the vertical coordinate, Y is the horizontal coordinate, in the Ads Factory context. If you remember that X means “first”, not horizontal, and Y means “second”, not vertical, the Ads Factory field names are self-consistent, and the code uses them correctly.

I haven’t seen any Ads Factory documentation which explains this, so I hope this note will help some of you Ads Factory enhancers who are using these fields.

Postscript: what did my client ask me to do with Ads Factory for their site?  Modify the radius search to search around the user’s latitude and longitude, instead of a location the user enters. Also, to sort the keyword and category search results by distance from the user. Quite straightforward to do, though it requires customisations to the Ads Factory code that have to be re-done everytime one upgrades the Ads Factory component.

USPS rates updated on USPS and Canada Post Rate Cards

Posted by Jim DeLaHunt on 21 Apr 2011 | Tagged as: Canada, USA, robobait

Last January I got around to introducing my handy Canada Post and USPS postage rate quick reference card on this blog. On April 17th, 2011, the United States Postal Service put new, higher postage rates into effect. I’ve revised my rate cards to reflect the new USPS rates.

Continue Reading »

How to resolve EasyEclipse error ‘Eclipse… requires plug-in “system.bundle”‘

Posted by Jim DeLaHunt on 31 Mar 2011 | Tagged as: robobait, software engineering, web technology

I use the EasyEclipse distribution of Eclipse, the free (libre) software development environment. I just figured out how to fix an obscure error message:

Eclipse Web tools editors (2.0.1) requires plug-in "system.bundle"
Eclipse Data Tools (1.5.1) requires plug-in "system.bundle"

When I would start up EasyEclipse (version 1.3.1 for Mac OS X, with Python, C++, Java, PHP and more support added), it would tell me that I had some outdated components, and offer to update them for me.  But when I opened the menu item Help… Software Updates… Manage configuration, I would get the ominous error alert:

“The current configuration contains errors and this operation can have unpredictable results. Do you want to continue? [Cancel] [OK]”.

I wasn’t able to  find documentation about this problem specifically. (My purpose in writing this is to help others benefit from what I learned.)

Continue Reading »

Handy Canada and US postal rate quick reference, updated

Posted by Jim DeLaHunt on 21 Jan 2011 | Tagged as: Canada, USA, robobait

Living as I do with one foot in the USA and one foot in Canada, I find myself sending letters from Canada to Canada, Canada to the USA, and sometimes carrying mail with me over the border to mail in the USA to the USA.  I have one pile of Canada Post stamps, and another of US Postal Service stamps. But looking up the various postage rates, with their grams and ounces, was a nuisance. I couldn’t find a single rate card which covered both countries succinctly. And with each service raising its prices about once a year, my improvised rate cards were going out of date every few months.

Nearly two years ago I came up with a handy quick reference to current Canada Post and USPS postage rates for basic letters between the USA and Canada. Last spring it was polished enough that I posted it on my web site. I just now updated it to reflect the Canada Post rate increase which took effect on 17. January. You can find it at http://jdlh.com/en/pr/postage_card.html.

Continue Reading »

Transparent PNG images in PHP: imagesavealpha() versus imagecolortransparent()

Posted by Jim DeLaHunt on 30 Nov 2010 | Tagged as: robobait, web technology

Are you using PHP (or libGD) to generate PNG images?  Are you having problems getting your text anti-aliased, and also having your “transparent” colour recognised as transparent?  Well, I had that problem too.  libGD, the component which PHP uses to handle image operations, gives you a choice: you can have anti-aliased text, or a designated colour as transparent… but not both.  Here’s why, and what you can do about it.

Continue Reading »

11 Django gotchas

Posted by Jim DeLaHunt on 31 Aug 2010 | Tagged as: Python, Unicode, robobait, software engineering, web technology

This post has been a long time in the making. A year ago, I started work on my Twanguages code. This was code to analyse a corpus of Twitter messages, and try to discern patterns about language use, geography, and character encoding.  I decided to use the Django web framework and the Python language for the Twanguages analysis code.  I know Python, but I was learning Django for the first time.

Django is really, really marvellous.  When I tried this expression, and got the Python array of records I was expecting,

q2 = TwUser.objects.annotate(ntweets=Count('twstatus')).filter(ntweets__gt=1)

I wrote in my log, “I think I just fell in love. Power and concision in a tool, awesome.”

But Django gave me fits.  It has its share of quirks to trap the unwary novice. Eventually I began writing notes about “Django gotchas” in my log.  Some of them are Django being difficult, or inadequate. Some are me being a clueless novice, and Django not rescuing me from my folly. But all of them were obstacles.  I share them in the hopes of helping another Django novice.

Here are my Django gotchas.  They are ranked from the most distressing to most benign. They apply to Django 1.1, the current version at the time. (As of August 2010, the current version is 1.2.1.) A couple of gotchas were addressed by Django 1.2, so I moved them down to a section of their own. The rest presumably still apply to Django 1.2, but I haven’t gone back to check.

  1. API fails unhelpfully. I wrote a simple query expression like:
    S2 = models.TwStatus.objects.get( key )

    I got a lot of weird errors, e.g. “ValueError: too many values to unpack” (where key is string) and “TypeError: ‘long’ object is not iterable” (where key is long). I had made a mistake, of course; the call to get() should have a keyword argument of “id__exact” or the like, not a positional argument. The correct spelling is this:

    S2 = models.TwStatus.objects.get( id__exact=key )

    The gotcha is that Django’s .get() isn’t written defensively. It isn’t very robust to programmer errors. Instead of checking parameters and giving clear error messages, it lets bad parameters through, only to have them fail obscurely deep in the framework. If defensive programming of the Django API would slow it down too much in production, I’d love to have a debug mode I could invoke during development. Continue Reading »

« Previous PageNext Page »