Posted on

Unable to run mksdcard SDK tool CentOS

Android Studio Banner

Installing the Android Studio on my CentOS 7 development system went fairly well once I loaded the latest Java JDK from the standard yum repository.   During the install wizard I did run into an issue with a generic “Unable to run mksdcard” error message.    This is the studios watered-down message from the actual command execution.   You can get more details by going to ~/Android/Sdk/tools and running mksdcard from the command line.


# cd ~/Android/Sdk/tools

# ./mksdcard

Here is where I found the compiled executable was missing some 32-bit libraries that are required to run the exe.


bash: ./mksdcard: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

A bit of digging and I found I needed glibc, which after another attempt to execute mksdcard told me I also needed libstdc++.so.6.  By using yum whatprovides libstdc++.so.6 I learned both packages I needed to install.   These additional installs helped get Android Studio up-and-running on CentOS 7.


# sudo yum install glibc.i686

# ./mksdcard
./mksdcard: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

# whatprovides libstdc++.so.6

libstdc++-4.8.2-16.el7.i686 : GNU Standard C++ Library

libstdc++-4.8.2-16.el7.i686 : GNU Standard C++ Library

# sudo yum install libstdc++-4.8.2-16.2.el7_0.i68

 

With those couple of new libraries installed the Android Studio app is now running on my CentOS 7 development box with the MATE desktop UI.

 

Posted on

Rhomobile : rhoconfig.txt cheat sheet

We have recently been working with Rhomobile to test and deploy some business class mobile apps.  So far the testing has gone well, however the documentation at the Rhomobile site is lacking in some areas and has fallen behind the mainline development.  The Rhomobile forums are also a good source of information but it is obvious Motorola is having some trouble keeping up with the developers that seem to be discovering this hidden gem (pun intended… Rho is ruby-centric).

As we learn more about developing with Rho, we have found some unique things about the environment.   Here we post some notes and hints.    We will add comments or extend the post with more hints as we come across them.

rhoconfig.txt

splash_screen settings

The following settings are the possible values in the 3.3.3 release:

  • splash_screen=’zoom’ (default)
  • splash_screen=’none’,  android = no effect
  • splash_screen=’hzoom’, android = no effect
  • splash_screen=’vzoom’, android = no effect
  • splash_screen=’hcenter’, android = no effect
  • splash_screen=’vcenter’, android = no effect

Derived from the source in <installdir>
uby\lib
uby\gems\1.9.1\gems
hodes-3.3.3\platforms\shared\common\SplashScreen.h and SplashScreen.cpp

There are developer notes in some “random forums” that this was re-factored in 3.3.3 to always zoom/stretch to fill the screen at all times (zoom).

 

 

Posted on

Phonegap Barcodes on IOS

Introduction

This article covers building barcode scanning apps on IOS (iPhone/iPad) with Phonegap.   For reference, Phonegap is going to become Apache Cordova any day now, so the process can be confusing if you are looking at older materials.  Before we get started we make the following assumptions about your development environment:

  • Operating System is OS/X Lion
  • Your IDE is XCode 4.2
  • You have installed Phonegap 1.5.0 or higher
  • You have downloaded Phonegap Plugins

While the general process will work with newer and possibly older versions, this is the environment we have tested this process with.   Also, if you mix versions of Phonegap and the plugins you will have naming convention problems, especially if you mix recent plugins with and older Phonegap install or vice-versa thanks to the transition from Phonegap to Apache Cordova.

We recommend following the links above as Google search results may bring you to older code.   We also recommend that if you had an older version of Phonegap that you install the latest version and start a new Cordova project via XCode with the new install.    Once your test app is successful you can follow the Upgrade Guide that will be included in the docs section of the downloaded zip file.

Our example app is named “abundascan”, which is also the default target that was created.  You will see that name in the screen shots included herein.

Step 1: Build A Starter Cordova App

Start Xcode and create a new Cordova project.  Build your project and run it in your simulator or directly to your connected IOS device.  This will build the template project.

Step 2: Add The Cordova Source Files

After you’ve downloaded and unzipped the files from the Phonegap Plugins page you will have a phonegap-plugins folder full of various plugins.   There will e a subfolder named “BarcodeScanner”.  This is the folder that will have the contents you need.

Highlight the following files and drag them from that folder over to your XCode window and drop them under the <target_name>/Plugins subfolder:

  • CDVBarcodeScanner.mm
  • zxing-all-in-one.cpp
  • zxing-all-in-one.h

Step 3: Edit The Cordova Plist

This file provides the symbol table references that will be used to connect the JavaScript components to the compiled plugin.    Find the Supporting Files folder under your <target_name> folder and click on Cordova.plist.

This will show the key/type/value table int he main editing window.  Click on the arrow next to Plugins to expand that section, then hover over to the right of the word “Plugins” to get the add/subtract entry buttons.  Click the plus to add a new empty line.

In the new line enter org.apach.cordova.barcodeScanner as the key name.  Note the capital “S”.

In the value column enter CDVBarcodeScanner.

Step 4: Add Link Libraries

In order for the project to compile in the new BarcodeScanner library you will need to add some new core libraries to your build commands.   In Xcode click on the target in the left hand sidebar (this is usually the topmost line under which all other items reside).   The project summary should appear in the main window. Click on the Build Phases top tab.

Open up the first Link Binary With Libraries group.   At the bottom of the expansion is the add/remove buttons.  Click on the + to add a new library.    Type in the following names (partial search will work) and add these libraries to the list:

  • AVFoundation.framework
  • AssetsLibrary.framework
  • CoreVideo.framework
  • libiconv.dylib

Note: You may need to click on the IOS5 folder when the quick search is running to see your matches.  

Other Settings

ZXing.cpp Optimizations Off

You may also need to turn off optimization for the zxing-all-in-one.cc file.   To do this, expand the compile sources group.  You will see a half-dozen file names with the last one likely being zxing-all-in-one.cpp.    This is actually a 2-column listing, if your screen is not wide enough you will see a “C…” trailing on the top right of the group.  Go just to the left of this and move your mouse in the header slowly, you will see the expansion double-headed arrow.  Click and drag to the left to expand this column.   Now double-click in this column to the right of the zxing-all-in-one.cpp file and add -O0 (letter “oh”, number zero) and click done.

No ARC

Do not use ARC (Objective-C Automatic Reference Counting).  If you did not turn this OFF when starting your project you can go to the Build Settings tab, scroll down to the Apple LLVM compiler 3.0 – Language group, expand it, and look for “Objective-C Automatic Reference Counting) and set it to no.

Add JavaScript and Run

Now you just need to add the reference to the barcodescanner.js file in your HTML files for the app and bind a click or hyperlink to the JavaScript barcodeScanner.scan_code call.     Run and you should be able to activate the scanner.

 

Posted on

Rhomobile: Error In Build Application

You are build Rhomobile apps on Windows, aren’t you?  If so, we’ve been there.   Luckily the fix is somewhat simple, though time consuming.   Sadly, it is a joke that Rhomobile can’t deal with SPACES IN DIRECTORY names.  What year is it?    Rhomobile is not aware of Windows 7 directory naming standards?  How sad.

Anyway, here is the fix.  And you might was well do it for ALL of the directories we note here are you will just postpone more problems that will inevitably arrive.

Install ALL the Rhomobile tool kits in directories without spaces.   For example:

Rhostudio goes in C:\RHOSTUDIO\<blah>

Java Development Kit (JDK) likes to live in C:\Java\jdk-6<blah>

Android Native Development Kit (Android NDK) goes in C:\Android\android-ndk-<blah>

and lastly…

Android Software Development Kit (Android SKD) goes in C:\Android\android-sdk-<blah>

When you are done installing (likely re-installing if you are here) the software you need to go and update your Eclipse project to set the new directory paths.  Start with Windows/Preferences and look for the Rhomobile entry, change the Java path there.  Now expand that entry and select Android and update the paths again.

Also, don’t try moving the JDK or Rhostudio folders.   Uninstall and re-install and you will have better results.

 

 

 

Posted on

Rhomobile: Error interpreting erb code

You are build Rhomobile apps on Windows, aren’t you?  If so, we’ve been there.   Luckily the fix is somewhat simple, though time consuming.   Sadly, it is a joke that Rhomobile can’t deal with SPACES IN DIRECTORY names.  What year is it?    Rhomobile is not aware of Windows 7 directory naming standards?  How sad.

Anyway, here is the fix.  And you might was well do it for ALL of the directories we note here are you will just postpone more problems that will inevitably arrive.

Install ALL the Rhomobile tool kits in directories without spaces.   For example:

Rhostudio goes in C:\RHOSTUDIO\<blah>

Java Development Kit (JDK) likes to live in C:\Java\jdk-6<blah>

Android Native Development Kit (Android NDK) goes in C:\Android\android-ndk-<blah>

and lastly…

Android Software Development Kit (Android SKD) goes in C:\Android\android-sdk-<blah>

When you are done installing (likely re-installing if you are here) the software you need to go and update your Eclipse project to set the new directory paths.  Start with Windows/Preferences and look for the Rhomobile entry, change the Java path there.  Now expand that entry and select Android and update the paths again.

Also, don’t try moving the JDK or Rhostudio folders.   Uninstall and re-install and you will have better results.

 

 

 

Posted on

App Inventor First Impressions : Coding An App

Google App InventorWe finally got our first App Inventor mobile application built and are underway on our second app. Here are our first impressions of building an actual app.

First App – The Pat A Cat Tutorial

The initial tutorial went very easily, after the fight to get the development environment set up. The first application took less than 5 minutes to create and get working, even in a standalone packaged app sent to my phone. I glossed over the “pet a cat” tutorial then created it without referring to the docs. It was very intuitive.

Second App – Barcode Scanner

The second attempt was a basic prototype of a far more complex application that was created with Eclipse and the Android SDK combined with the open source Zxing project. The idea is to have a simple bar-code scanner that when it scans a valid bar code calls a URL for one of our client sites and returns back the price they will pay for a book, dvd, cd, or video game.

With the initial Eclipse based project we had a standalone and fully self-contained app on-line within a hour. It worked well for a prototype and provides all the elements we need for a full blown app. It has to be coded in Java and requires a coding background.

With App Inventor we have a few hurdles as outlined below.

Hurdle 1 : Separate Install of Zxing Required

The built-in scanner class requires a third party application, the freely available Zxing App, to be pre-installed on the phone. That means if you were to put this into production all of your users would be required to go fetch and download another app before they could use this app.

Hurdle 2: Checking/Launching Third Party Prerequisites

Maybe I’m missing it, but I don’t see a simple way with the drag & drop interface to check if a third party app such as Zxing is already installed when running my new test app. That means we will only be able to wait until someone tries to scan, catch the error (we have error catching abilities, right?  We’ll need to look into that), and then tell them to exit the app and go install something else then come back.

There also does not seem to be any way to automatically launch a third party app other than the select few that Google App Inventor supplies. So that means not launching the marketplace and sending them a “search for zxing” command. Luckily we can launch a web browser with a URL, but that is not exactly the same.

Hurdle 3: Bundling Other Apps/Libs

The best solution would be to bundle the other app along with our app so that installing our test app automatically installs Zxing. Even better would be the ability to make it a self-contained component within our test app.

Test 2 Summary

All-in-all we could knock together a simple prototype of our new scanner app, but it would be a rudimentary version of the final app. Not being able to bundle Zxing easily and, even better, including the libs directly in our project, makes it hard to sell this as a consumer friendly application.

Of course this is a new IDE we are playing with here. Maybe all of this is possible for the expert App Inventor developer, but for a noob the methodologies are not readily apparent.

Initial Thoughts

After a full day of playing with App Inventory, here are my initial thoughts. The environment is perfect for simple to somewhat moderate level applications. It is good for things like a basic toddler app or a simple limited use consumer app. It may even be able to do some more complex tasks.

It is not going to build something like Angry Birds. Not even close (I know, that is not really what this IDE is for, at least not yet). It also is going to be difficult to create anything that is not based on down-the-middle business forms or simple media interfaces. Showing pics, playing sounds, firing off the camera or phone apps… no problem. But trying to complex interactions with any of those devices becomes more & more of a challenge to the point that learning some Java and using a full blown IDE starts to make sense.

So for a casual mobile app hacker that wants to create some simple apps for their kids, themselves, or their business it is great. It is also a good prototyping tool. Heck, you can even create some marketable apps here with some effort. At some point you will outgrow the environment and will want to start learning Java. This is a great way to get a layperson interested in the craft of computer programming though, and even teach them the basic concepts of logic and device interaction along the way. A perfect 101/201 level class in application development.

The only problem for a large number of casual app hackers is that you may need a comp sci Phd just to get the environment setup. And therein lies the rub. Google App Inventor is obviously targeted squarely at non-technophiles, the layperson that has an idea and a little bit of computer coding knowledge, NOT a hard-core tech geek. Yet, as you may have noticed in my prior posts, just getting setup can be a trail in patience and computer expertise. Yes, I have a “talent” for making technology break… any of the guys on my team will tell you that, but I assure you I’m not the only person who  will run into problems.

A promising start, and a great fit for the right people. We’ll probably use Google App Inventor for some of our own simplistic apps and definitely for more than one prototype. However, for prime time level A applications it is not there yet.

Posted on

App Inventor First Impressions : Setting Up

Google App InventorIn the previous article I went over some of the notable items on the Terms of Service for Google App Inventor. Here we get into building our first simple app.

App Inventor and Java

While you don’t need to know how to code in Java, you will need Java installed on your computer. Don’t worry, your computer probably already has Java on it. If not, it is usually a simple process to install or upgrade Java on your system. It is not any more difficult than installing or upgrading Flash. That said, sometimes getting Flash or Java upgraded and installed can be a challenge depending on your computer security settings, hardware, disk space, memory, and other unique factors that require you to hire a Comp Sci major just to get started.

Notes about App Inventory and Java…

  • Requires Java 6.
  • Upgrading (or intsalling) Java can be a challenge on some systems.
  • Get Java at http://www.java.com/inc/BrowserRedirect1.jsp?locale=en

Java Exposes It’s Ugly

Now that we have our Java environment up-to-date we can get started. Surf to your App Inventor login and launch the program. If everything is going well you can follow the Google tutorial and start creating your first app, a picture of a cat that will meow when clicked.

This is where things get ugly for App Inventor and Java.

There are 3 main parts to creating your App Inventor mobile app:

  • The App Inventory Palette – where you draw your interface by dragging & dropping components onto a mockup phone.
  • The Block Editor – where you drag and drop logic components using a puzzle analogy. In essence you are writing Java code visually.
  • The Phone – connecting your Android phone is your staging (or testing) environment to see how things really work when “glued” together.

All was going well. The palette came up, got the button, the photo, the MP3 file all in place. Got the phone connected and the PC loaded the device drivers for the HTC Incredible being used as the test device.

Ok… let’s start writing some code. Fire up Block Editor. And…

We get “Java Ugly” in full effect. While Java has some very cool things that deserve bragging rights, over a decade into its existence and it still retains the uglies UI contest hands-down. Not only do all default Java interfaces look like they were designed for a 1987 character based terminal, they are often less than helpful in helping you interact with whatever files, folders, devices, or web addresses you need to resolve a problem.

In my case the “command interpreter” that allows the App Inventor to talk to the phone cannot be found. The ugliness ensues:

"Java Ugly" Command Directory
“Java Ugly” Command Directory

Yikes. Welcome to 1987.

Fixing The Missing Blocks Command Directory

Turns out that I missed an important step before setting up my environment. Not only do you need to upgrade/install Java, but you also need a desktop program that Google App Inventor uses to communicate with the phone (among other things). The Windows version is here:

http://www.appinventorbeta.com/learn/setup/setupwindows.html

Next Problem : Windows And Google Not Playing Nice

The next problem we run into is that the Block Editor cannot talk to the phone. It just doesn’t see it. After reviewing the App Inventor setup program we learn that you should “not change the default installation directory”. Virtually every single app on my computer goes on my 500GB D: drive, NOT the default C:\Program Files directory.    Wow.  Really, “don’t change the default install location”. Back to 1987 I guess.

So we uninstall the application.  Re-install it in the default place.   All is good, right?

Well, not so fast. Now the Block Editor is looking in the original D:\ install location but it cannot find some of the necessary components.

Great. Copy all the components over from the C:\program files directory. Still not working. Uninstall and delete EVERYTHING. Reboot…  we’ll be right back…

Windows Serves Up EPIC Fail

We’ll be right back, my butt. On the reboot windows decided my Windows account no longer exists. I was immediately greeted with a rather useless “The User Profile Service failed the logon.” message as soon as I tried to get into my Windows account on my local PC. Great. Off to safe reboot & finding the answer.

Now for the favorite part of my app development experience. REGISTRY EDITING.

Yup, that’s right. To restore my account back to normal I had to edit the windows registry. What fun. Luckily that is all it took and the instructions I found on the Microsoft Support site actually worked. If you ever need to do this yourself, make sure you sacrifice the requisite number of goats then follow this link:

http://support.microsoft.com/kb/947215

Try, Try Again

PC back online. Check.

Re-install the appinventor_setup_installer_v_1_2.exe.

Open up the Google App Inventor at http://appinventor.googlelabs.com/. Check.

Open up the Block Editor. Check.

Ohhh… wait… no devices found. The editor is open, but it can’t talk to my phone. The phone is in the proper USB debug mode. No communication with the device. Wonderful.

It turns out that the AppInventor_Setup_Installer executable that we downloaded (all 90MB) may NOT have the proper driver for the HTC Incredible phone, even though Google notes it as one of the phones that works with this development IDE. Now we need to go to the HTC site and find the right driver and try this all over again.

Just to make matters even more fun, there is no simple “HTC Incredible” device driver. However, even with the phone attached to my PC and visible as an external device, a visit to the Device Manager in windows shows it as an unknown device with a name like “ADB”.

Setting Up HTC Drivers for Windows

So here I am, no obvious HTC Incredible drivers. Some hints on the “Internet at large” indicate that the full blown 30MB HTC Sync application, WHICH I DO NOT WANT, will have a driver for the phone packaged up in there. I sure as heck hope it doesn’t mess with my already working perfectly Google Sync program that keeps my contacts, calendar, and email all perfectly in sync with the Toshiba Thrive table, HTC Incredible phone, and my Windows desktop. We’ll see.

For now, I sit and wait… going on 15 minutes now… for a 30MB file to be downloaded from what must only be direct via mainland China on the 宏達國際電子股份有限公司 (HTC Corporation in case you’re wondering) website. I’m on a 50MB/10MB line, but this is slow as heck. Must be getting interrupted by some goats, stray chickens, and a stray tank rolling over the fiber line before it tunnels it’s way under the Great Wall on the way to The States. Man this is slow. Guess I’ll go practice more guitar lessons while I wait…

…I’m back.

Installation of the HTC Sync program got the drivers. Sadly I had to start the installation, let it install Adobe AIR, the HTC driver, and some other junk then cancel out right at the start of the actual HTC Sync installation. At least I got out of that.

Next.. maybe we can code our first app.

Not So Fast…

Wow, this sure is a LOT of work for a supposedly easier way to develop Android mobile apps. I had Java, Eclipse, the SDK and my first mobile app written the “old fashioned way”, you know… with CODE and an tried & true ID like Eclispe, done in much less time than the 4+ hours getting this setup.

My intention was to write a quick article on actually using the App Inventor IDE, yet here I am writing about how to setup the IDE and how to install drivers and how to debug a failed Windows login.

So much for quick & easy.

Hopefully the next article will be about actually creating a usable app with App Inventor.  Stay tuned.

Posted on

App Inventor First Impressions : Signing Up

Google App InventorGoogle App Inventor is a service and development platform provided by Google to make it easier to create and deploy Android mobile applications. I am reviewing the viability of this platform now that the technology has matured a bit and is gaining more acceptance in the community. It appears this project may have some longevity, which is always a concern with any Google endeavor.

One of the risk factors of a service like this is that the provider can pull the plug at any time. As many companies have learned along the way, if you rely on a Google Labs project as a core part of any project you may well find yourself re-inventing and re-creating on relatively short notice. Google has a history of dropping anything they consider a failed project with little advance warning.

Terms of Service

Nobody ever reads this things. You should. Especially when it comes to basing your next big money making software product on a platform somebody else OWNS. That’s right, Google OWNS the platform. That means they can make changes that directly impact your ability to produce, update, and continue to sell your project. If you’ve got the next Angry Birds on this platform you really don’t want rely SOLELY on an external organization, even one that will seemingly be around “forever”.

Here are some notable items in the TOS from Google App Inventor:

4.2. Google reserves the right (but shall have no obligation) to pre-screen, review, flag, filter, modify, refuse or remove any or all Applications from the Service. Google reserves the right to directly take down any Application that violates these Terms, any applicable Program Policies, or applicable law or regulation.

In other words, Google can pull the plug on your project at any time for any reason and even stop your product from being listed in the first place.

4.4. You agree that Google has no responsibility or liability for the deletion or failure to store your Application and other communications maintained or transmitted through use of the Service. You further acknowledge that you are solely responsible for securing and backing up your Application.

If they do pull your project, oh well. You are on your own. You cannot sue them if your $5k/month revenue stream suddenly goes away because they pulled your app.

5.3. Except as provided in Section 7, Google acknowledges and agrees that it obtains no right, title or interest from you (or your licensors) under these Terms in or to any Application that you create, submit, post, transmit or display on, or through, the Service, including any intellectual property rights which subsist in that Application (whether those rights happen to be registered or not, and wherever in the world those rights may exist). Unless you have agreed otherwise in writing with Google, you agree that you are responsible for protecting and enforcing those rights and that Google has no obligation to do so on your behalf.

Unlike some other online services, Google does not get any ownership of the project you post on this service. What you create you own.

7.2. You agree that Google, in its sole discretion, may use the trade names, trademarks, service marks, logos, domain names and other distinctive brand features of your Application in presentations, marketing materials, customer lists, financial reports and Web site listings (including links to your website) for the purpose of advertising or publicizing your use of the Service. 7.3. If you create an Application to share with other users of the Service, you may determine with whom you share the Application and grant to such users a non-exclusive, worldwide, and perpetual license to perform, display, and use the Application.

While you retain ownership of your app, if you have the next runaway hit Google can leverage your brand awareness to their benefit. In other words if you create the next Angry Birds app, Google can promote the heck out if it in their marketing pitch for their service… “Joe’s Super Cool App was created with Google App Inventor” and plaster that message all over the place. I see no real downside in this, but it is something to be aware of in case you later think “hey, they should be paying me to use my notoriety” once you get rich & famous.

What Is App Inventor?

App Inventor is a project manager and web based IDE (integrated development environment) for Android mobile apps. Like most IDEs these days the App Inventor starts of by being a graphical design environment. You “draw” how you want the app to look first, then connect functionality later.

“Real” programmers don’t necessarily like this as it can allow for some very sloppy coding. It also allows programming “noobs” to get in on app development without understanding the design principles of creating sustainable applications. However it is a great way to start an application for a mockup or to create simple applications that don’t require complex process flows.

In Progress…

I am now off to create my first App Inventor app. Stay tuned for follow up articles on the Google App Inventor IDE.

Posted on

Upgrade Issues from MooTools 1.2.4 to Mootools 1.3.2

This past week we worked on some site updates for Abundatrade.  During the updates we attempted to upgrade Mootools from 1.2.4 to 1.3.2.  Unfortunately this did not go as well as expected.  After 8 hours of trying to get it to work we ended up rolling back to Mootools Core 1.2.4 with Mootools More 1.2.5.1.   Here are some of the pitfalls.

$empty Is Not Defined

The first problem was with the FormCheck library from floor.ch.   The library requires the “old-school” $empty function definition from MooTools.   This has been deprecated in later versions.   It also turns out it is a pain to replicate, though we were able to patch around this by adding a this.$empty function() {} definition to the JavaScript library.    After doing so we ran into more problems with undefined methods so we gave up and ended up loading MooTools Core 1.3.2 with compatibility.  That resolved both the $empty definition problem as well as some other issues we had with failing code.

Unintended Recursion

The bigger problem that forced us back to v1.2.4 was an unintended recursion problem in one of our AJAX calls that queues and consumes requests to/from a back-end server script that feeds JSON back into the main web document. With all versions up to 1.3.X the system works as we expect, you put in a UPC, click “Add Item”, it is sent to the back-end for real time pricing lookups, and a single row is added to an on-page table showing the item and the offer price. With version 1.3.2 the call to the back-end system is now working as a factorial function.  The first time you add an item you get one call to the back-end. The second time you get 2 calls, by the 6th added item you have a table full of duplicates that is growing exponentially. Not good.

We dug around for answers for most of the day yesterday, but nothing obvious was uncovered. The basic culprit is a form submit handler that eventually does something like this:

function MyHandler() {
… this.set(‘send’,func () { do stuff; });
this.send();
}

The first time through it works perfectly. Subsequent iterations are looping through the this.set call, as if this is now an array of handler objects.  There must be a way to reset the form handler stack to be a single instance, but damned if we can find it. The problem appears to be triggered by a change in the MooTools library that now handles the anonymous function definition differently as it is no “array aware”.

MooTools 1.2.X Problems

Unfortunately, staying with MooTools 1.2.4 presents another problem.  The spinner class breaks for Internet Explorer 9.  With the spinner class in place the submit form handler fails.   Thus for MooTools 1.2.4 we are stuck with a subset of the UX.

The failing code:

        document.id('top_content').set('spinner',
            {
                hideOnClick:true
            }
            );
        document.id('top_content').spin();

 

Summary

There is probably a design flaw in our code, but it is not easy to unwrap and simply turning on MooTools 1.3.2 with compatibility mode is not fixing it.  So much for the easy way out.  For now we’re back to MooTools 1.2.X and moving on.  Other projects await.   If you have any hints on what the issue may be please share.

Posted on

Sharing a Class In ASP.NET Pages

It’s easy enough to create additional classes that can be used in the code behind files of an ASP.NET page, but what if you want to share a class among the ASP pages themselves? It’s quite common and easy to develop generic methods and event handlers that can reduce repetition of code and simplify the process of creating the different parts of your UI. In a recent project, I needed to create such a class and make it available to all my ASP pages. The class contained two methods that were meant to be called by the DataBind event of a GridView or DetailView in order to assign Javascript confirmations to all the Delete Commands and looked something like this…

namespace ProjectNameSpace {

 public class AdminUI {

 public void add_delete_confirmations_to_grid_view(object sender, EventArgs e)
 {
 // Do stuff
 }

 public void add_delete_confirmations_to_detail_view(object sender, EventArgs e)
 {
 // Do stuff
 }
 }
}

Now that we have the class, we need to find the way to make it available to our ASP pages. The usual way to do this is via an entry in the web.config that makes the namespace available like this….


 
 
 

…which works fine if you intend on calling the method using ASP tags…

<% AdminUI.add_delete_confirmations_to_grid_view(); %>

…but the methods above aren’t mean to be used in ASP tags. They are meant to be assigned directly to events of ASP Controls like so…

<ASP:GridView OnDataBoundEvent="AdminUI.add_delete_confirmations_to_grid_view">

…which sadly, does not work. This seems to be something that was overlooked in ASP.NET. The former compiles, but the latter generates a “AdminUI namespace not found” type of error.

So in order to get around that, we are going to have to make use of inheritance.

Normally, the code behind classes for an ASP page are children of the System.Web.UI.Page like this….

public partial class Users : System.Web.UI.Page { }

Therefore, I can construct my AdminUI class as a middle layer between my ASP classes and System.Web.UI.Page by changing AdminUI to…

public class AdminUI : System.Web.UI.Page {}

… and all of my ASP classes to something like this…

public partial class Users : AdminUI { }

… and the assignment of the methods to their corresponding events becomes this…

<ASP:GridView OnDataBoundEvent="add_delete_confirmations_to_grid_view">

…and it works perfectly. All the methods that normally would have to be duplicated in multiple code behind files are in a centralized location and inherited by all of the classes so they can be used directly in the ASP pages without triggering a compiler error.

Posted on

Detecting USB Insertion/Removal in C# .Net 4.0

We need your help!


Cyber Sprocket is looking to qualify for a small business grant so we can continue our development efforts. We are working on a custom application builder platform so you can build custom mobile apps for your business. If we reach our 250-person goal have a better chance of being selected.

It is free and takes less than 2 minutes!

Go to www.missionsmallbusiness.com.
Click on the “Login and Vote” button.
Put “Cyber Sprocket” in the search box and click search.
When our name comes up click on the vote button.

 

And now on to our article…

C# Programming

Introduction

While coding a new Windows desktop app for a client we ran into something that we thought we be fairly simple.  It has turned out to be a rather complex task. The goal: detect when a SmartDongle USB key was being inserted or removed & update our application interface at that time.

Our assumption was that a few minutes of searching the Internet and we’d find a dozen examples of people that have done it already or we’d just use the .Net 4.0 classes for device detection. Wrong on both counts. As ubiquitous as USB devices are these days, it appears that .Net 4.0 still does not have direct support via easy-to-use classes that you can just hook into. Searches of the Internet turned up a lot more people asking questions than viable answers. The few answers we found were outdated or half-answers.

Now that we’ve got basic USB insertion/removal detection working we decided we’d share that part of the solution. Our next challenge is to determine that we’ve inserted the SmartDongle and not some other USB device such as a keyboard, mouse, flash drive, or other USB item. Unfortunately the message handler we’ve got thus far only tells us that a device has changed (windows message WM_DEVICECHANGED), but does not hand off the parameters that would let us query the message stack to find out WHICH device changed. That will be a solution for another post I guess.

Our Environment

We are coding in C# using Visual Studio 2010 (VS2010) with the .Net 4.0 framework helping us along. We are coding a WPF main window, not a form, which can make a difference.

Our Solution

Here is the simplified way to detect that a USB device was inserted or removed from the system, and our call to a ReadDongle method that we wrote to get information from the dongle header (or not, if it was removed). You can call whatever function you’d like, or put your processing loop right inside the windows process handler.

using System.Windows.Interop;
...
public partial class MainWindow : Window
 {
    ...
    public MainWindow()
    {
    ...
    }

    //============================================================
    // WINDOWS MESSAGE HANDLERS
    // 

    private const int WM_DEVICECHANGE = 0x0219;  // int = 537
    private const int DEVICE_NOTIFY_ALL_INTERFACE_CLASSES = 0x00000004; 

    /// <summary>
    ///
    /// </summary>
    /// <param name="e"></param>
    protected override void OnSourceInitialized(EventArgs e)
    {
        base.OnSourceInitialized(e);
        HwndSource source = PresentationSource.FromVisual(this) as HwndSource;
        source.AddHook(WndProc);
    }

    private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
    {
        if (msg == WM_DEVICECHANGE)
        {
            ReadDongleHeader();
        }
        return IntPtr.Zero;
    }

}

Summary

That’s it, now we know when a device is inserted or removed. We are overriding the OnSourceInitialized method for our main window, which basically is saying “hey, when the window is initialized and ready to accept external messages from the operating system, add a hook that latches onto the window’s message processing method (WndProc). We can then perform operations by sniffing out specific types of messages like “device changed” (WM_DEVICECHANGE) and doing our thing. When the WndProc override is done it drops back to the default method for further processing. We could override that by setting handled to true, but we don’t want to do that in our app… not yet anyway.

Hope our article helps provide a quick shortcut for someone that is googling stuff like “C# wpf usb insertion/removal”.

Posted on

Starburn SDK and .Net 4.0

Introduction

We have been trying to get StarBurn to play well with others for a client project we have been working on lately. The problem is that StarBurn is very particular about the Windows environment, and though the support guys mean well the communication is sometimes hard to decipher. I don’t think English is their primary language, but can’t fault them there… they communicate much better in English than we speak French, or any other language for that matter.

Anyway, we deciphered some of their clues, experimented a bit, and finally came up with a step-by-step guide for getting the latest StarBurn SDK working well with our .Net 4.0 project. If you don’t get the right DLLs activated it will wreak havoc on your Visual Studio debug sessions and will not play well on most final release installs.

Step-By-Step

The first step is to make sure you have registered the StarBurn.X12.dll in your system registry via regsvr32:

1) Download & install latest StarBurn version. Make sure you have a January 2011 or later copy of StarBurn installed.

2) Run CMD as administrator. Search for “cmd” from the windows start menu, then right-click and “run as administrator”. If you do not run as admin you will get a cryptic error from Windows when using regsvr32.

3) CD to the StarBurn install directory. From the command prompt cd “…path-to-starburn-install”.

4) CD to the \Bin\Core\StarBurnX\x86 subdirectory.. Yes you could have done this all in one step, but I like to have the subdirectory spelled out so it is easier to find next itme around.

5) Register the DLL. Enter the command “regsvr32 StarBurnX12.dll”. You should get a message back with no errors saying the DLL was registered.

6) Remove any references to blah-interop-blah if you have them in your project. These references are wrong. Remove them. If you copied the setup from the sample solutions, they reference the Interop files, which is typically all you have to start with if you try registering anything StarBurn in your project prior to doing the regsvr32 trick noted above.

7) Add the corrrect StarBurnX 12.0 Type Library COM reference. Go to your project and add references. Click the COM tab. Look for the newly available “StarBurnX 12.0 Type Library” reference. This is what you want to add for .Net 4.0 Client Profile projects.

StarBurn COM Install
StarBurn COM Install

 

Manifestations

Here are some of the things you’ll see if this is not done correctly.

  • Application crashes immediately on boot.
  • Error code 8007007e simply means that a DLL that the application needs is not registered with the system.
  • A common error when you have problems with StarBurn is “Retrieving the COM class factory for component with CLSID
    {B756C224-A1EA-44F8-95C1-9F726040C800}
    failed…”. You can look for the CLSID by using regedit and searching for that string. This particular Class ID is registered to StarBurnX.StarBurnX, you can find it under HKCR/StarBurnX.StarBurnX/CLSID

 

Hope that helps some of you StarBurn developers out there.   It sure took us a while to figure out the best way to do this, maybe this will save you a few hours.