AppForge to NS Basic Switchers

These are unsolicited comments from people who have switched from AppForge to NS Basic/Palm. The most recent comments are at the end of the file.

If you would like information comparing AppForge to NS Basic, see this Tech Note.

I just want to say... Ohmygod! I just looked at Appforge... Sorry, But I needed to know. Do you know how big their runtime is? Jeez! It's 334k!! Needless to say, I think I'll stay with NS Basic. try telling someone they need a 334k file PLUS the size of your program installed. They even have the nerve to call it small! Must be a bunch of WinCE heads. ;)

Anyway, just telling you that you guys have a great product and I'd love to help make it better. -- Wes

I first came across NSB for PalmOS before it was called NSB and thought it had a lot of potential. However, it was buggy to no end but again it had potential. Then the name was changed to NSB and the first iteration was an improvement but still there was a long way to go. I never plunked down any money as I was just trying demo versions that were available to determine if the cost was justified.

In the mean time I started to "use" CodeWarrior demo (painful) and GCC tools (painful but free) and I bought the Palm Programming Bible an awesome piece of work. The book shows how things are done using GCC and CW and I learnt a lot. But the development process was slllllooooowwww.

Downloaded Appforge and compiled a couple of programs. While the integration with VB is cool the implementation of interface on the Palm is IMHO hideous not to mention the 300+ kilobyte runtime.

I had being turned off NSB for quite a while because I could not gauge the progress of the software as no demo was available. However, last week I did download a demo and my reaction was holy s*** this thing has really matured and I plunked down my $99 for version 2 and I haven't stopped coding since.

This really is a remarkable piece of software when you consider the C way of doing the same thing with CW or GCC.

Anyway, thanks George and the crew as NSB Corporation and all posters to this group that I've being lurking in, on and off, for the past year or so. -- Gary Christian

I also own AppForge and it does allow you to use the same code for a Palm and a CE, I just tell it which to compile into. That being said, it did cost $800 for the dual-compiler capability, it cost $10 for every CE run-time module (free for Palm), it has a HUGE footprint on the run-time modules, I've found it less stable than NS Basic, and it's slow. It did look like a Palm screen on a CE, but with what I'm developing and my circumstances - that's OK. They're also tinkering with other things where there would be distribution charges on some planned 'super' capabilities - so they're going to goof themselves up if they're not careful. Their customers are developers, not customers of the developers.

So even though I have both AppForge & NS Basic, I develop in NS Basic (but prototype in AppForge). For a user community and support, there's no comparison with AppForge & NS Basic. NS Basic is miles ahead. -- Mark

As a recovering AppForge developer I can tell you first-hand that AppForge has shot itself in the foot not to mention the terrible treatment it gives it's own customers.

They require access to certain proprietary PalmOS Source in order the develop the PalmOS Booster Runtime.

For a year now, AppForge has been telling developers that it can't provide a Booster for OS5 because PalmSource won't license Booster from AppForge. This is completely false.

The reality is that PalmSource has an exclusive arrangement with another company for SDK source code. AppForge will not be supporting further version of PalmOS and they refuse to admit this to their customers.

The irony is that the AppForge product was first developed for PalmOS support. When they went from v1.x to V2x they radically altered the object model and the runtime environment and became dependent on PalmSource for proprietary source code.

I switched to NSBasic after it became clear that you can't even get a direct answer from AppForge about their plans for OS5 Support. I have had shouting matches with AppForge corporate officers because of how they treat customers that made their business. I even Cc'd John C. Dvorak to get the word out to the development community not to get suckered by empty promises from AppForge.

I'm much happier with NSBasic and have no intention of ever giving AppForge another dime. Regards -- Tim Markoski

Here are my main gripes with the other packages. By the way, I happen to own several. I have been writing programs on the pda since 1998, so I have a little practice at it.

Also, I make my living based on the programs that I sell. Mostly Field Service applications. So, I need my tool to work for me and to progress over time. Actually, we create full scale, multi-tiered client server programs. We use both the hotsync for local synchronization via cradle and Scout Sync for remote syncs via cell phones in the field. On the back end, we always have MSSql server, Oracle or DB2.

Here is the story in case you guys want to hear it. Its a little long, but its worth mentioning.

I have tried most of the tools out there over the years and I will give you my opinions. I currently have several applictions, some rather involved, using sat forms and/or AppForge. I even use the Scout sync from Aether to sync multiple palms simultaneously over the internet. I have lots of money invested in this because it is how I make my living. So please understand that there is a lot of merit with what I am about to tell you.

Pendragon forms is cheap and easy to work with. It is very capable but is the low end development tool. If your requirments are simple, will stay simple and you are not the most experienced programmer, then it is a good choice. I started with this one but had to move up because my requirements became more sophisticated. This is not a high end tool.

Then I moved to SatForms, version 2 at the time. It was 1998 then. It was good and the programming model was more traditional. There were a lot of bugs initially, but they worked them all out. I still primarily use it. The performance is really good considering that it is an interpreted language. The real benefit is the sfx controls you get from www.palmdatapro.com. Why build features when you can buy them. And its cheap to buy the controls. But, SatForms itself is now expensive, the support is amongst the worst I have ever experienced. But this was a while ago. It was so bad that I determined that I would never attempt to call for support ever again. This bad support trend started when Pumatech bought the product from SoftMagic. But a more stable product means that support is no longer needed. With the scripting language, you can code around most things. SatForms in an excellent tool in my opinion.

So I stayed with SatForms for the past 4+ years, all the time cursing the lack of support and communication from Pumatech.

At one point I was so frustrated with the support at Pumatech that I tried everything possible to get away from them. It was quite uncomfortable for me to base my living off of a product that had so many bugs and a support staff that was largely unresponsive (again, this has probably changed). So I bought NSBasic 2. It was and still is great. I would rank it almost even with SatForms in terms of capability and ease of use. As far as support goes, the NSBasic crew provides an unbelievable level of support and response, including issuing patches to fix problems. In all my days, I have never seen any company stand by their product like they do. But, Satforms and NSBasic are so much alike, that it was not worth my while to switch. My apps have anywhere from 35-70 tables and forms and there would be no benefit to changing. If I were starting something new and did not want to spend $1000 on a development tool, there is absolutely no doubt that I would go with NSBasic. It it better than Satforms today because it fully supports color and it supports all versions of the palm os including palm os 5.

Appforge has all the external appearances of a company that has their finger on the pulse. They have a truly unique cross platform development tool for palm, pocketpc's, nokia, etc. They have an enormous runtime but that is only an issue for older devices with only 2mb of memory. It is large but you never seem to run out of space. They have a set of user interface controls that is excellent. They have Fancy grids, dropdown boxes, etc... and they use custom fonts. SatForms and NSBasic uses only the standard palmos fonts and controls. Your user interface will always be much more attractive using appforge. BUT, the external appearance fades quickly because you cannot code to the palm os 5 devices. Appforge charges a runtime, which is ok for me since all of my apps are commercial and I roll the costs in to my product price. Its usually 10-25$ per device. For palm os prior to 5, Appforge somehow got palm to pay them money so that they wouldn't charge developers for it. So, we never paid for runtimes on palm devices, only the others. With palm os 5, AppForge is trying to hijack Palm Inc. into making another payment to support the the tungsten device. Obviously palm refused. Therefore, appforge is now telling everyone that they cannot support palm os 5 devices because Palm Inc has not agreed to pay the fee. So, as good and as powerful as appforge is, it is USELESS because it lacks support for the new palm pilots. I would rather that they make the runtime available for a fee so some of us could get our work done. I have just finished converting my appforge application to SatForms so that I can run it on palm os 5. I probably won't take another look at appforge ever again. (money wasted)

So, I ported all of my AppForge programs back to SatForms because I was most familiar with it.

All of my customers are companies that tend to have older equipment (palm 3's and palm os 3.0.1). One of them bought a Tungsten device. Well, the version of Sat Forms that I was using did not support Palm OS 5. So I purchased an upgrade for $695 and converted my program. I installed it on the new device. It worked fine, but then I lost support for all my devices palm os 3.5 and lower. There was no backwards compatibility. To top it off, there were annoying little bugs that were not evident upon first using it. Naturally, Pumatech issued a email to everyone letting them know that there were known bugs and that they would send out a patch by the end of the month. It is not good for a guy like me to have bugs out there, but I had no choice. To make the customer happy, I went out and purchased 3 Palm M505 for them to temporarily use since these devices still ran on Palm os 4.1. Then I rolled back the version of SatForms to use. (I was trying to save face at this point, remember, I make my living on these programs that I sell for about $300 per user.) You might think that I could simply have two different PRC's, one for OS5 and one for OS4.1 and below. But that would make me look foolish to my customers. They are bound to load the wrong PRC on the wrong device. It is a support problem waiting to happen.

That was over three months ago that I started waiting for the next patch to SatForms.

So there I was with a $1000 appforge package and a $1000 Sat forms package, neither one being either forward or backwards compatible

Sat Forms is really an excellent tool and is equivalent to NSBasic is many ways. But do I tell all of my customers to throw away their Palm 3 and Palm 3E devices. What about the Handspring visors that many of them have.

I had been following this group over the years and I realized it had an excellent community of followers and contributors.

So, I have decided to make the switch and port my applications over. A couple of things prompted the timing on this. 1. I am out of money for buying upgrades for products that don't work. 2. I am "feature saturated" on my current programs and am now on a six to 9 month upgrade cycle. I have until the end of the year before I have to roll out a new version. 3. I have sold the source code to my bread and butter program to my biggest client. They are hiring their own programmer and Sat Forms is now their problem. But they will be happy with it for now. 4. I have started development of 2 new applications that I think will be my bread and butter for 2004.

So I am giving NSBasic a chance. I am also looking forward to building PocketPC programs for the first time. Honestly though, my customers really don't care about devices. They focus on the application running on the device instead of the palm os vs. pocketpc issue. Most of them just think "pda". I like palms becuase they are cheaper and easier to use. But I need to have options. NSBasic Palm and NSBasic CE are an attractive combo.

So, this weekend, I jumped right in and built a small 8 form utility using NSBasic Palm. I figured out the database stuff pretty easily. I even built a large 2000 record table with sample data to test the access speed. It is instantaneous when accessing it by key. I am writing a little more code that I used to with Sat Forms, but that what programmers have to do.

The look and feel of SatForms programs and NSBasic programs are about the same, so it will not be difficult to build the interfaces that I am used to. I am looking forward to the use of color on the screens. I am really excited about being able to manually load my popup lists manually instead of binding them to a table. I am really looking forward to not having a proprietary pdb format an being able to have palm database that I can easily share between programs. I also look forward to eventually becoming a contributing member of this group (after I learn a little more)

However, I will miss the filters and sfx controls with SatForms. I will also miss that Sat Forms had a built in ocx that automatically integrated with the hotsync process. But it is not worth keeping just for those.

The IDE in Sat Forms has a few little things that I am sure will mature over time. For example, if I get an error during compile, the bad line of code is highlighted, but I cannot type over anything until I click it. (this is insignificant in the grand scheme of things). After one weekend, I can clearly see that NSBasic apps run faster and I have significantly more control over the code.

So, there is the story. I have been quite successful over the years with sat forms. Me and my family have been eating and our bills are paid. But knowing what I know now, I have decided to transition to a tool that will take me into the future.

I now have to figure out how to build a hotsync process that will allow me to connect to a MSSQLServer database directly. (Any recommendations would save me the trouble of trying them all)

I also have to figure out how to convert the signature string into a windows BMP. I am sure that I will find and example somewhere. (By the way, storing the signature as a string is a genius idea)

Exchanging data with corporate databases (local or remote) and signature capture are the keys to selling applications to corporate customers. I now have to figure these things out.

Thanks for reading... -- Maurice Dorris

I want to let you and everyone at NS Basic Corporation know how impressed I am with the product and the level of support available from yourself and the Yahoo forum.

Your product has made the migration from AppForge an easy one. I never thought working with Palm databases could be this easy. The NSBasic IDE is incredibly easy to navigate.

The quality of your product has saved me well over 100 man hours in porting the AppForge code to NS Basic.

The best part is that code execution is fast and the compiled *.prc file is now almost 50% smaller than with AppForge. NS Basic even reads the AppForge converted *.pdb files!! AppForge can't read any database file other than it's own.

I can't wait to dive into NSBasic/CE !! Thanks again for a stellar development tool!!

Regards- -- Tim Markoski, CNC Machinist Software "Software Tools for Today's Manufacturing"

IMHO

AppForge is the path of madness (and in my case, unemployment!). Go with NS-Basic or re-implement in C/C++.

you did ask.. -- David M

Thank you. And please pass on my thanks and appreciation to your developers and team for developing this product. I have managed to develop in less than a week, an application that my organisation needed, having previously struggled with other applications over the last month, and thousands of pages of documentation. Your tools is easy to use, friendly and doesn't require a rocket science degree.

Palm SDK - didn't want to download entirely and support from Palm was almost insulting;
Code Warrier - didn't even want to start properly;
PDA Toolbox - simple to create basic apps, but rather limited for anything useful;
AppForge - difficult to follow, although allowed a "bolt-in" to .Net Developers Suit;
WinSoft Pocket Studio - looked very promising, given I am a Delphi man, but very limited documentation and functionality was totally different to normal Pascal;

Your product was well documented, and clear to follow. I just need to figure out how to create a Conduit now for my PC application, and am trying to use the Palm Conduit SDK ... again, hard to follow -- Paul Elliot New Zealand

But consider that they have always targeted the corporate developer, typically producing custom applications for in-house use. In this context, time is money, and their claim to fame is being able to take VB developers and transition them to multi-platform handhelds with a minimal amount of being aware of OS specifics or variations. Indeed, what they try to achieve is project platform independence, where you design a project once and compile to either Palm OS or PPC executables, allowing the company to develop their own application and deploy to both platforms at once.

That's a nice goal, and in a large corporate environment, may well justify the costs for the tools. The real problem is that it doesn't pan out quite so well, from what I understand. Part of the problem is that to be platform agnostic, they have to avoid using many of the OS services and traditional user interface objects. So AppForge forms don't have real text fields etc. Instead, the entire form is comprised of gadgets (from the OS perspective), and then there is this massive "booster" runtime which performs all the gadget magic and makes them appear to be a text field or button or label or checkbox or whatever.

The benefit of this is it allows them to mimic properties which don't officially exist, such as color attributes for specific fields etc. And it means the apps can have the same look and feel regardless of handheld used. That can be a benefit in a corporate help desk situation, but it also means the apps may not have the look and feel of a traditional Palm OS application.

One nail in AF's coffin was the transition from OS4 to OS5. Their "booster" runtime which handles virtually all the form processing would not easily port over from the Dragonball m68k cpu to the ARM architecture used by OS5 devices. It took nearly a year (as I recall) for AF to even introduce the OS5 booster. During that time, corporate users of AF who might otherwise have been early adopters of high-end OS5 devices, could not run their AF based apps at all.

And even when they did get a OS5 booster, it didn't have the advantage of real OS based user interface objects which ran at an optimized level deep in the OS.

Corporate developers are a vastly different market than hobbyists. When key executives are wanting to get a new fancy OS5 device, and after many months are still being told the applications won't run on them unless completely rewritten in a new language, the IT department can take a lot of flack. It is no wonder that AF developers have many unhappy campers among the lot. JMHO, Doug Handy

You may find the history of our products interesting. They have both been featured as a case study for AppForge (http://www.appforge.com/corp/case_studies/datakinetics.html and http://www.appforge.com/corp/case_studies/soccer_assist.html) (in fact, I still have the Lava lamp that AppForge was giving out to the companies that were the first case studies on their site). We have been using AppForge from the original release. As you probably know, we have spent thousands of dollars on the AppForge products.

What has lead us to redoing our products using NS Basic are the recent changes by AppForge. After we upgraded to version 5.1, a few months later a new version was released (chargeable). In addition, adding a fee for the runtime (Crossfire client) is just a $25 profit hit per sale. Also, with the new OS's not being supported by the Booster that we use (forcing an upgrade), we decided to rewrite the application completely using NS Basic rather than continuing to invest in the AppForge "money pit". Fortunately, most of our code can be ported with minimal changes. -- Mark J. Hogan, Pharm.D. President MDK, Inc.

From what I can tell, the author of HB++ has a very high opinion of himself and the product. I have tinkered with HB++ and like some things about the interface, but he is charging 10x more for the comparable product to NSBASIC and charging to support it (for God sake support software without charging to work around errors in the software).

I switched from Appforge (VB 6 is my favority IDE). I have found NSBASIC powerful, user friendly, and constantly improving. The support is the best I have ever seen...from what I can tell, the author of the most used reference and the help desk folk are on this community board always.

HB++ and Appforge are literally an order of magnitude more expensive..are they an order of magnitude superior...for me NO!!!!!!!!...but, that's ultimately for you to determine. -- Tom Powell

As for the differences between NSBasic for Palm and CE, I am sure I'll be able to figure it out. The actual code in my app is not that complex, the hard part is really just developing approximations to the flight performance charts, which I do with MATLAB and Excel. I think I will just go ahead and order both versions of NSBasic so I can take advantage of the $50 off. I'm also excited to see that there are many other developers that make tools for use in NSBasic.

OK, I've taken enough of your time. You've got a great product, I'm looking forward to getting lots of use out of it. Cheers -- Scot Seaton, US Navy

Appforge vs NsBasic:

Appforge takes over the VB6 development environment with some very cool technology. You write applications using the VB6 IDE and compile to Appforge using menu options added by Appforge. I rate this technology very highly. One reason I like VB6 is that the language is forgiving in terms of variable typing. If using Appforge within Vb6 you lose this and must basically assume that you will always be using Option Explicit and never using variants. Overall I liked the Appforge development environment but thought their run time required too much overhead, didn't like my DBMS options or how the client piece was licensed. My frustration level grew to the point that I decided to abandon our AppForge projects and adopt NSBasic. Why? My run time projects were sluggish, didn't care for the performance of the DBMS Appforge suggested (PDB database) and didn't like the hassle of dealing with their client piece. My biggest issue was with the client piece. I look at my Appforge experience as a waste of time and money in retrospect.

NsBasic is a completely different animal yet remarkably similar in many ways. I'm a NSBasic newbee and I am so far very satisfied. NSBasic provides its own IDE which is not as sophisticated as VB6 but is intuitive and easy to use for a Vb6 programmer. I felt comfortable working with the NSBasic IDE for WinCE after about a day of poking around. This time would have been cut substantially if there was a table showing what Vb6 syntax items are not supported and what the NsBasic workarounds are.

With NSBasic all variables are variants and you run the app on the PDA not in the IDE. I happen to like the fact that all variables are variants; I see it as an advantage over the strong typing required with Appforge; I'm sure many purists will disagree. With NSBasic you don't run the app in the IDE and you can't single step through an app like you can in VB6; this is probably the biggest practical difference between the two systems. With NSBasic you basically compile and copy your app to the PDA (its easy to do) and debug using msgbox tracing and/or logfiles. Debug messages when running on the PDA reference the line# where the problem has occurred and this is accurate enough to be fairly quick once you get the hang of it.

One caveat is to make sure that a broken program actually is out of memory on the PDA before trying a new version. This is easy to do once you learn how, but its important to get the concept that a broken program may be running in memory and refreshing with a new copy doesn't automatically remove the old program. To save time you can run the app on the PDA but remotely access and control the app from the desktop using one of many remote access tools.

In terms of the language NSBasic is sufficiently close to Vb6 that you will feel very much at home if you are a Vb6 programmer. NSBasic incorporates some Microsoft technology that is not actually part of the NSBasic language but can be used as if it were part of the language. I didn't get this concept at first and didn't realize that for these items you must look at Microsoft documentation. FileIO is one example of this where the File and FileSystem objects are actually resources provided by Microsoft.

My apps seem to run faster with NSBAsic than Appforge and NSBasic supports the SQLite DBMS which is a wonderful DBMS that works well on desktop and PDA platforms. One especially cool NSBasic feature is the ability to add objects on the fly. I haven't leveraged this yet in my applications, but it opens the door to some very cool application ideas. Hope this helps. -- Ken Levin

(15 days after purchasing) "I'm 99% done with the conversion. The good thing is that it works faster now and seems more resilient. With Appforge, we used to get spurious errors that no-one could solve. They seem to have disappeared so far. The real testing will be next week when the engineers get their hands on the new version.

Because the NSB code is pretty similar, a lot of stuff could just be copied and pasted. Screen layouts took a while, although the pixel co-ordinates were the same, so it was just a long process.

There were a few things missing from NSB, but there were other solutions in NSB to compensate. For instance, Appforge could have Record types, so you could declare a type and use an array. In my application, for example, the client downloaded a site history and stored the details in a record array, displaying each one as the user went through the records. I've been able to use SQL Lite to hold the data instead, constructing a SQL Select statement where necessary.

This SQL Lite approach makes checking data easier though. Before I had to ripple through and array to see if there were any blanks, forcing the engineer to complete the details. Now I just issue a SQL query to return the blanks instead.

Appforge relied primarily on PDB files too, so searching was slow. I have a parts database of 15000 records, so in NSB I can issue a SELECT statement to get the record(s) I want. In Appforge I had to split the files because indexing wasn't very good.

The end result is that I'm pleased with the conversion and NSB in general. It's not quite as slick to use as Appforge was, but then they had 50 developers and a pile of debt." -- George Kirkwood

"So far, I like NS Basic a lot better than Appforge. We should have used NS Basic instead of Appforge to begin with." -- Bill Strehan