- #NSB APPSTUDIO ALTERNATIVE PDF#
- #NSB APPSTUDIO ALTERNATIVE FULL#
- #NSB APPSTUDIO ALTERNATIVE ANDROID#
- #NSB APPSTUDIO ALTERNATIVE CODE#
I have also developed applications in Visual Studio and. It seems to prove my suspicion that it should still be possible to build today's applications using a simple language and IDE as we did in the past. My company has tried other mobile toolkits and the learning curve appears to be much greater than your intuitive product. Having mostly written applications using Visual Basic 6/SQL Server and various reporting tools over the last few years it was really easy to start working with your product and actually build something and see it working quickly. "I was very impressed with your NS Basic app studio product - my company will definitely purchase a copy shortly having tried out the demo version.Ī few comments (sorry this seems to be quite long!) So for me, NSB gets a thumbs up, and I am sure that in the future it will change to a big thumbs up as the GUI/Editor/documentation issues are resolved. But it sure is a lot easier if you only need to develop for one device and screen size. So far everything I tired worked, some better than others. Now I cannot afford to buy every device out there and I don't even own a Mac, but whenever I am near someone with a device I like to do a little test.
#NSB APPSTUDIO ALTERNATIVE FULL#
Oh, and it had to look good, with either a full picture image background stretched to fit or tiled to fit, and all controls were re-sized and centered.
#NSB APPSTUDIO ALTERNATIVE ANDROID#
But most important it had to run everywhere, on anything: PCs, Macs, Android and Apple devices. It connected to my server, exchanged data, sent email both from the app and the server, allowed for internal correspondence (social networking?), maintained a database (SQL on both the server and the app), used local storage in place of cookies, had a "coded" splash screen form which of course worked on iOS, and much much more. I wanted it to be an "everything/everywhere" app. My second app with NSB was a lot more aggressive. Third something or other: "monogamy is best but polygamy can work, just not as well". Oh, and don't forget the best "add-in" of all: this forum (thanks Less for that great procedure to ease building dual portrait/landscape apps). Solution, a java script add-in for the conversion and phonegap to save the file.
#NSB APPSTUDIO ALTERNATIVE PDF#
I recently wrote an app that had to convert an html text file to pdf format and then save it to the device drive for printing with a separate device driver to a Brother printer. VB6 has many things missing but there are a plethora of DLLs, VBXs and OCXs that make up for this. It couldn't handle keyboard entry the way I wanted so I wrote a machine language routine. My first Basic compiler couldn't do drop down menus so I bought an add-in. I have never used an SDK that had everything I wanted. Second rule: "If you can't be with the one you love, love the one you're with". But it really is still apples and oranges. No way, damn why couldn't VB6 have this great capability like NSB? Thank you "Just for Fun" for this suggestion and the NSB team for listening.
#NSB APPSTUDIO ALTERNATIVE CODE#
Did I like the quick response, advanced syntax checking, and debugging on my PC, yes, you bet I did? But then I kept finding myself highlighting groups of code and trying to right click to block comment. And then a few weeks ago I had some time on my hands and went back to a program in VB6. This is one reason I chose NSB, I could not do this in Java Script, even if I was proficient, the time to convert and debug, no thanks. I was trying to avoid rethinking the logic I used to create these routines and that was a success. I have since then gone back to many routines developed in VB6 and reused them in NSB, again after making some changes to syntax. I copied code directly from it to NSB, made a few syntactical changes, used the SDK to create the controls (similar to VB6) and that was it. My first app with NSB was a rewrite of a VB6 program. "First rule: don't compare SDKs, that's apples to oranges.
0 kommentar(er)
