Point of sale system mobile devices - Amicus PDA

sburman — Fri, 24 Jul 2009 17:24:51 +1000

This week started by learning the ropes of Amicus PDA, basically a portable version of our Amicus point of sale software. The developer who built this system has left the company so we had to figure out how he got past several hurdles.

The PDA emulator was relatively easy to setup. As long as you had Windows Mobile Device Centre version 6.1, it was quite easy. All that had to be done was start the Device Emulator Manager, make sure itâ€™s setup for DMA, and the following options are turned on:

â€¢ allowing automatic device authentication
â€¢ allow data connections on device when connected to PC

Cradling the PDA would then allow us to interact with it.

The next fun part was attempting to get merge replication working. There are many steps required in order to get this to function correctly. Most of them are in a doc that we use. However, the basic way it works is to do the following:

â€¢ Make sure that every record in the database has a GUID.
For us, this was a problem as the system was created a while ago, and therefore doesnâ€™t use GUIDs for primary keys. We solved this by creating a DTSX package to transform the data into a useable state within a separate database.

â€¢ Create a local publication so that a snapshot of the secondary database is created.
This allows subscribers to connect to the publication. This is how merge replication works.

â€¢ Within the PDA, use the SqlCeReplication class that comes with .NET. After setting it up to point to the snapshot, the replication method happily did what it was supposed to.

It sounds simple when summarised like this, but there are so many options etc that need to be used that it feels like we need to get out the magic luck crystals every time we set it up.

Visual Studio Crash Fail

sburman — Mon, 21 Dec 2009 11:20:29 +1100

I fixed a rather interesting crash this week. Our main program maintains a dialog list. From this list, we can perform actions on our dialogs such as â€˜close allâ€™. When a user logs off from the program, it closes all the dialogs. However, one of our very old dialogs was causing a crash when this happened.

The problem with this crash is that we could successfully reproduce it in release mode on a testing machine, but if we tried it on a development machine (in either release or debug), it would not fail. As a result, we decided to try some message box debugging. We could have tried remote debugging, but this hopefully would have been a small issue to find.

What had happened was that the crash was due to a simple null pointer. Because it was an old dialog, it didnâ€™t do what a lot of our new dialogs do, and ended up trying to access the dialog object after the dialog was destroyed and reset to null.

The strange part about it was that Visual Studio did not complain when this happened. Even when I found the cause, and debugged to the point where it should have crashed, Visual Studio continued to work, and the program went on as if nothing happened. Strange (and annoying).

Amicus point of sale syncronisation

sburman — Mon, 27 Jul 2009 16:40:50 +1000

One of our supporting products that comes with the Amicus point of sale and business management systems is a windows service called nbsSync. This service is responsible for synchronising data between a set of Amicus POS databases. Eg databases at different sites for Amicus point of sale system.

This tool can be configured to only synchronise certain tables, and deal with conflicts in a defined way.

As we are getting ready for the deployment to our largest customer in Vanuatu, we have had to make some changes to the system to make it cope with the ridiculously unstable communication lines they have there.

The initial implementation used purely the winsock2 API functions WSARecv and WSASend. When this service was written, we used these functions with infinite wait time. After running this service for a while, it was noticed that packets were clearly being lost over their communication lines, so introducing a WSAOVERLAPPED structure was needed so that we could introduce timeouts.

The example given on MSDN for the WSARecv function was used to implement the timeouts. In the example it was said that â€œIf 0 bytes are received, the connection was closedâ€. Since these are the people who wrote this function, this is what was implemented. When this service was rolled out in Vanuatu, it was seen that 2 of the sites that often had poor communication kept receiving 0 bytes. If the example is to be believed, this means the socket was closed. However, this was not the case. The code was altered so that in the receiving loop, it would no longer stop if 0 bytes were received, and we made the loop itself timeout if nothing was received after a given time. This seemed to make things work.

Amicus POS software testing

sburman — Mon, 17 Aug 2009 10:46:10 +1000

As any developer who has worked on a large project is aware, unit testing goes a long way to making sure the end product is stable. Amicus point of sale and business management software also has unit tests. These are test cases written in code to make sure that the software is behaving. They will never replace testers, as a unit test is only ever as good as the person who made it. But they make sure that the developer has written decent code, and make sure that other developers do not accidently break functionality of existing code later.
We use CruiseControl.NET for automating the build process. This causes the build server to always build an entire release of Amicus POS every time a developer checks in code. It ensures that a developer will not check in code that is broken, and therefore prevent other developers from working.
What I have been working on is setting up a new CruiseControl.NET server for automatically running unit tests. We decided to go for another separate server for 2 reasons:
1. It takes the load off the build server, as that should only be for building
2. We needed an XP server, because some of our old C++ unit tests require GUI to be created. XP allows the creation of GUI from a service.
The build server project was extended slightly to create all the files required for running the unit tests. These were all placed in a central folder. Then once a day the automated test server copies the files from this location and runs them. We keep the building side of the process on the build server, as that saves us having to setup another server with all the build tools required to build Amicus POS.

Amcus POS PDA in Vanuatu

sburman — Wed, 26 Aug 2009 10:40:27 +1000

As mentioned in previous blogs Amicus is a point of sale software application. Amicus also has a PDA based application. This application allows the user to do a lot of the main functionality that can be performed on Amicus through a PDA. This is great for warehouses and similarly large businesses.

After our latest version rollout of Amicus point of sale to Vanuatu, one of the wholesale sites started complaining about issues with submitting stock adjustments through Amicus PDA. It looked as though the adjustment was being applied more than once. This instantly made me wonder if there was some other piece of SQL being called after the stock adjustment creation. As expected, the record was reloaded after the stock adjustment was created. The developer who was assigned to the task fixed this by placing both pieces of SQL within a transaction.

After this patch was applied, another issue came up where the tills would lock up a few times a week. These types of issues are hard to track down. Our head tester was in Vanuatu at the time, and happened to realise that the staff were running the stock adjustment report at the same time as the till locked up. The staff members were complaining that it was running slower than it ever used to.

From these signs we figured that there must be some connection between the transaction, and the report. However, the action of creating a stock adjustment and reloading it are not complex or time consuming at all. After looking closer at the reloading SQL, we noticed that one of our junior developers had called the stock level calculation SQL when fetching the record. They used the version that calculates it from scratch rather than using the current stock level cache. If a product has not had a stock take for a while, this would be a very costly piece of SQL. This explained the locks and the report running issue:

â€¢ The lock was due to the fact that running complex reports will cause lock ups.
â€¢ The report issue was due to the fact that the transaction prevented the stock adjustment from being committed until after it was committed. But because we had to wait for the stock level calculations, this would cause a greater wait then needed.

Now that we identified the issue, we had to figure out what to do about it. This ended up being an easy fix. It turned out that the stock level was not even required in Amicus PDA. The only time it was required was in the unit tests. So this complex SQL was being called for nothing. The junior developer should have called the SQL himself in the unit test to make sure the stock levels were correct, and not have put them inside the code that was use in the released version of Amicus PDA.

Amicus POS Customised Reports

sburman — Tue, 01 Sep 2009 15:02:09 +1000

Point of sale and business management system Amicus has a huge variety and number of reports that end users can run. This includes product significance, sales transaction, customer and employee tracking reports. Despite having such an extensive set of reports, every business always wants at least one of the reports to be slightly different than the standard set. If there was a common pattern, we would change that report, but usually it is a change that only that business wants. This usually leads to our technical support guys saying to us â€œI wish there was a way to write custom reports for clientsâ€. It was this motivation that lead to the designing of the custom reporting module.

At this stage, the custom reporting module is not even in the design phase. We have been prototyping the custom report editing features of DevExpress to see if we can bend it to our needs. So far, it is mostly going well. We have been able to figure out ways around all problems thrown at us so far, and will be starting the designing today.

The DevExpress framework for creating custom reports allows for a graphical user interface for designing any report the end-user wants. We are taking this framework, and overriding certain features. When implemented this designer will have 2 plugins:

â€¢ The report designer module â€“ This is used to create reports and save them to the database

â€¢ The report runner plugin â€“ This is used to run any custom reports found in the database.

Automatic updates

sburman — Mon, 07 Sep 2009 12:31:35 +1000

When combining .NET with native C++, we use CLR (common language runtime). The thing about CLR is that you have to make sure that the side-by-side configuration is correct before you are able to run it on another machine. This problem is easily solved by making sure that the Visual Studio redistributables are installed before running the application.

Windows update played around with this recently for us. Our local machines allow Windows to update itself along with other Microsoft applications. However, the build server (which we use to further develop Amicus, our point of sale product) does not do this. All server updates need to be reviewed before installing. Unknown to us, one of the recent updates was to Visual Studio and the redistributables. This meant that any piece of code compiled on our machines would no longer run on the build or testing server. It also meant that it would no longer run on a client machine either. It would complain that the side-by-side configuration would be wrong.

When we realised this, we updated the build server to match the version our local machines have, and updated the redistributables that come with Amicus POS. For now, we are preventing updates on our local machines. What we want to setup, is for our techs to install a SCS (system centre essentials) server so that we can monitor and apply all updates to machines when we want to.

Amicus POS software testing

sburman — Tue, 29 Sep 2009 15:02:29 +1000

I ran into another stumbling block while putting our automated tests onto the testing server. This time, the problem was with handling modal dialogs. A modal dialog is one that waits until the user closes it. This means that as the code progresses, it too will wait until the user has closed the dialog until it continues to run. The problem with writing automated tests around a modal dialog is that it is hard to tell when a modal dialog has been created.

This problem was originally put in front of us years ago. To get around it, we made a class called ModalHandler. This worked by creating a modeless dialog and a thread. The modeless dialog would be created, and the thread would wait until another window got focus. Once that happened (as a result of the modal window being created), the thread would terminate, and the modal handler would handle the window as it needed to. This solution worked great, until we attempted to put the tests onto the testing server.

The problem with the testing server was that it is a service. When dialogs are created, they are created in session 0. Therefore, any call to windows functions like GetForegroundWindow would result in NULL being returned every time. It was functions like these that the ModalHandler relied on. We could not solve this problem in a nice way, so instead we decided on a different approach.

All our dialogs extend a common class. This class is used for both modal and modeless dialogs. All we had to do was build in a static list that saved the window handle of any dialog created modally. Since this list was built into the foundation of our dialog classes, it meant that we simply had to use this list instead of the previous system. The limitation is that any 3rd party library modal dialogs cannot be handled. However, this is only needed to support old tests. Our policy now is to not create GUI tests anymore.

Amicus PDA Installer

sburman — Fri, 09 Oct 2009 09:15:39 +1100

One of our developers created an installer for our Amicus PDA project. As with Amicus point of sale and business management system, we wanted the build server to build the installer as well. However, we found that nant did not support installer projects. A bit of searching found that the way around this problem was to call the â€˜devenvâ€™ program directly instead of using the msbuild task. The net said to do it the following way:

After we got the build server to build the installer with â€˜devenvâ€™, we found that it wasnâ€™t working. The log said that â€œThe project type is not supported by this installation...â€. We then realised that the installer wasnâ€™t the problem, it was the web service project that the installer was installing that the compiler was complaining about. Several guides on the net said to install the following patches:

http://www.microsoft.com/downloads/details.aspx?FamilyId=8B05EE00-9554-4733-8725-3CA89DD9BFCA&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=bb4a75ab-e2d4-4c96-b39d-37baf6b5b1dc&displaylang=en

But this still didnâ€™t fix the problem. We then tried removing the â€˜/SafeModeâ€™ option, and all of a sudden it decided to work. Even though we tried this before, the patches obviously fixed the problem, but the â€˜/SafeModeâ€™ option prevented them from doing their job. After all that stuffing around, we finally got the build server to build the Amicus PDA installer.

Point of sale software feature requests

sburman — Wed, 21 Oct 2009 15:42:36 +1100

Now that Neotechnology Business Systems are establishing a partner network across Australia, weâ€™ve been getting Amicus POS feedback from partners. One suggestion was that they would really like to see the 3 main meal order screens within Amicus Hospitality combined into one.

Currently, we have the order screen (where you choose entree, main etc), category screen (where you select which meal ie rump, chicken), and options screen (where you choose â€˜well doneâ€™ etc). Each of these screens takes up the whole screen when showing, requiring the user to click through each screen.

The change that was required was to make the order always appear on the left, while the right section of the screen would show the category screen. When an item was added, the options screen would be shown on the right instead. This way, the order would always be visible to the user.

The implementation of this was interesting. It involved a bit of code cleaning up, as well as a lot of moving around. We decided to leave each screen as its own screen rather than moving them all into one. This was because it was less work, as well as that each screen was considerably complex in its own right, and to put that all into one â€˜super dialogâ€™ would make the code for that screen ridiculous.
The enhancement is almost complete. We are at the final stages where we are improving appearance and ironing out bugs before it goes to the testing team.