Archive for October, 2009

The New Canada Line

October 28th, 2009 by Darin Herle

I was recently invited to present at a Business Partner seminar put on by ESRI Canada in Vancouver (thanks Paul!) It gave me an opportunity to learn the latest from ESRI (Canada) with respect to changes happening in their partner program, and recent news from an ESRI platform technology perspective. Most importantly, it gave me the chance to talk to other partners about a lot of the success (and, pragmatically speaking, a few challenges) we’ve encountered as an ESRI Business Partner since 2001. Overall, a great experience.

skytrainOn a related note, being in Victoria (and separated from Vancouver by a large body of water!), the most efficient way to make my way to the event was by plane, and at this time of year, fog plays havoc with float plane schedules. As a result, I was a bit perplexed – how do I get there? Ferry? Helijet? Puddle jumper? Great – puddle jumper; but how to get from YVR, downtown? Aha! The new Canada Line! Opened with much ballyhoo recently for Vancouver 2010, this new light rail/subway line runs from the airport to downtown Vancouver. I hopped on the clean, “new car smell” train and arrived downtown 25 minutes later, and only $3.25 poorer. Awesome! If you’re coming to Vancouver for the Olympics, consider this option vs. the lengthy taxi lineup you’re sure to encounter…

How to export and import SharePoint web parts

October 27th, 2009 by S Woods

I’m often working on increasing the data flow between areas of our organization – using SharePoint as my channel. In the old days, if you wanted to make a web page that loaded dynamically and displayed information from a table of some kind, you pretty much had to be a developer. Not so any more! SharePoint has the facility to make web pages that are comprised of different building blocks called “web parts”. When you make a new web part page, you simply select web part templates and you then configure them using the “modify web part” option. These blocks are all stacked together on a single page like a newspaper. Often, I have several different pages that display information from the same source, only altered a little bit to display it differently for different people.

For example, say I have a List called “Employee Information”. I might display this List in a web part on a page designed for a manager that would filter the List by their team members so they could wish them a Happy Birthday. I might make another page for a receptionist that wouldn’t filter by anything so they would see all the employee birthdays so they could order cakes. These two pages would be fundamentally different, but they would both require the same web part: same columns, same view, same List data.

Making different pages with similar information can result in a number of repeated tasks, especially when it comes to configuring views and web parts. I learned early on that creating a view for the List instead of just the web part saved me a lot of time – I could re-use that same view for any web part I’d make from the same List. Unfortunately, it never occurred to me to take it a step further to find a way to “copy” web parts between pages.

If you are like me and tend to work with similar data on different pages with slight changes for the audience, then you’ll really appreciate this article on how to export and import a web part – essentially copying and pasting the web part. A word to the wise – not all web parts can be exported by default. If your web part isn’t displaying the export options, the workaround is incredibly simple (thanks to Chris’ comment on this post):

  1. Open the page in SharePoint Designer (I find “split” mode works best for this type of thing)
  2. Select the web part you want to export and look in the code to find the following: false
  3. Change false to true

Not all web parts are worth exporting, but if it’s going on more than one page and takes more than 5 steps to set up, I would seriously consider adding it to your web parts list.

Installation – A New Approach Needed

October 21st, 2009 by Kevin Rintoul

One of the things that most software companies have in common is that they struggle with software installation. For whatever reason, installing software seems hard. I estimate that installer development consumes at least 10% of software project’s resources and installation issues are the cause of 20% of support calls. I’ve even known companies that have had developers dedicated only to installation. At Latitude, we have a couple of developers with installer experience. Interestingly, when they are asked to fix installer bugs, they disappear faster than arctic summer ice.

I can see why developing installers is hard work. Consider that installer writers must concern themselves with at least 4 different versions of windows, countless service packages, optional windows component, at least 3 different versions of IIS, different levels of windows security, and upgrade issues. For fun, hobble your installer developer by telling him that he must use the most primitive tools devised by man but yet he must have a working installer in three days when the next scheduled release of your software will ship. Finish him off by telling him that when his installer doesn’t work, 1000 of his closest friends (your current customers) will be calling to personally complain to him. On second thought, maybe just paint a target on his forehead find someone to shoot him.

Over the coming months, we plan to revamp our installers and in doing so, will make them easier to work with and provide a much richer end user experience. Our approach will be to follow ESRI’s lead which is to create a very simply MSI-based installer that will ask at most two questions: 1. Do you agree with our license agreement? and 2. If so, where would you like to install our software? When the installer completes, a post installation step will execute that will take care of software configuration. The post install step will be developed using traditional desktop UI tools that will provide a much better experience for both the customer and the developer alike. Users will be able to run the post install step over and over again, reconfiguring the their software as their needs change.

I’m excited to work on this new project and welcome the opportunity to relieve a bit of the pain we’ve felt over the last while.

Geocortex Essentials 2.1 Released

October 15th, 2009 by Drew Millen

About 3.5 months have passed since our 2.0 release of Geocortex Essentials. Since then, we’ve been busy. We released a “dot” release (2.0.1) in late July but I have to admit that it’s more exciting to announce a major or minor release containing new functionality.

For Geocortex Essentials Web ADF Elements we’ve put a lot of work into features that our customers have been asking for like support for coded domains and subtypes, and identify on WMS and raster layers. There are a number of other features and quite a few bug fixes as well!

For Geocortex Essentials REST Elements we’ve focused our attention on extensibility and developer support. Specifically, we’ve added the ability for a developer to easily augment our REST API by standing up their own custom REST endpoint. Developers can also create custom Site.xml extensions to add functionality to sites.

We’ve included a lot more into this release than what I’ve mentioned here – for those interested I encourage you to review the 2.1 release notes on our support center download page.

Repairing MXD Data Connections

October 15th, 2009 by Stephanie Blazey

We have all seen the familiar red exclamation points when our MXDs have broken data connections. An MXD can take a long time to open when data paths are no longer recognized, so it may be faster to set data sources in ArcCatalog. Here are a few options to try for data repathing:

1. In ArcCatalog you can right click the MXD and Set Data Sources. It can take a while to open the Set Data Sources window, so leave it in the background. Once the window opens, select one of the layers and click the “Replace All” button to find and replace data paths:

set data sources 2

replace all 3

2. If you are not having success in ArcCatalog, you can try repathing directly in ArcMap. Open the MXD (may take a while) and right click a layer > Data > Repair Data Source, and navigate to the new location of your data. Connections of layers whose data are in the same location will also be repaired.

repair data source 2

3. Under the Source tab of the layer properties in ArcMap > Set Data Source. You can do this to repath one layer at a time.

layer properties 2

4. If you find this too time consuming, you can also try replicating the prior folder structure. For example, if the MXD was previously pathed to your colleague’s “C:\Project\Data” folder, then create a “C:\Project\Data” folder locally, and copy the data there. The MXD should open with no problem, then you can repath it much faster to another location.

I find it helpful to initially save MXDs with relative paths so they are much easier to move around. In ArcMap, click File > Document Properties > Data Source Options > Store relative path names to data sources.

Latitude Geographics' European office

October 8th, 2009 by John Austin

It’s an honour that my first blog post here at Latitude (I started in May of this year in an operations role) represents a groundbreaking step for the company. After careful consideration we have landed and set up shop in Rotterdam, Netherlands. Henceforth begins what we envision will mature into a full figured office with services and support functions, but at the moment represents the efforts of one man – Steve Maddison (formally of our Toronto operations).

Steve’s mission will see him travel far and wide across Europe spreading the value message of Latitude’s solutions. When he is not happily walking around in airports or driving the autobahn, Steve will be in the Groothandelsgebouw office in Rotterdam (pictured below) supporting our ESRI Netherlands partners and deciphering Dutch. If you are in the Netherlands be sure to look up Steve and say hello. He would be happy to tell you of his adventures to date…

ESRINL2

Latitude Geographics’ European office

October 8th, 2009 by John Austin

It’s an honour that my first blog post here at Latitude (I started in May of this year in an operations role) represents a groundbreaking step for the company. After careful consideration we have landed and set up shop in Rotterdam, Netherlands. Henceforth begins what we envision will mature into a full figured office with services and support functions, but at the moment represents the efforts of one man – Steve Maddison (formally of our Toronto operations).

Steve’s mission will see him travel far and wide across Europe spreading the value message of Latitude’s solutions. When he is not happily walking around in airports or driving the autobahn, Steve will be in the Groothandelsgebouw office in Rotterdam (pictured below) supporting our ESRI Netherlands partners and deciphering Dutch. If you are in the Netherlands be sure to look up Steve and say hello. He would be happy to tell you of his adventures to date…

ESRINL2