LiveCode Forums.

I'd very much like to see more direct out of the box support for field validation, customization & input masks.

For example boolean properties to create a date entry field (with calendar!), bulleted password field, auto entering values eg date or serial number, perhaps even an expression builder?

Anyone who has used Filemaker, MS Access or their ilk will understand how easy basic field input and authentication can be and this ability looms very large when deciding what tool to use especially when faced with building a database front end.

Best Regards

Chris

chriswood wrote:I'd very much like to see more direct out of the box support for field validation, customization & input masks.

For example boolean properties to create a date entry field (with calendar!), bulleted password field, auto entering values eg date or serial number, perhaps even an expression builder?

Anyone who has used Filemaker, MS Access or their ilk will understand how easy basic field input and authentication can be and this ability looms very large when deciding what tool to use especially when faced with building a database front ends

As a FM user too, I think you're perfectly right.

Even though... all what you're asking is really simple to create with RunRev. And once you've designed your own functions (or found them with other RunRev users, everything is available out there), you can reuse them easily, just copy and paste.

[and by the way, we could compile all those little bits in one single stack, see at the end]

Albeit... I believe that for RunRev, the company, it would cost... really nothing to add those functions, natively. And from a marketing point of view, it would increase the appeal of RunRev with beginners (and/or people who want to go really fast).

As for the criteria of choices, there I disagree with you. I'm not sure input fields and validation methods will help you to discriminate between a solution based on FM or RunRev etc.

But more likely :
-single or multiple users (FM, or RunRev+SQL Lite, or RunRev + MySQL etc.)
-costs (let's not forget, that's usually a very important criteria !)

Actually, with RunRev, now, we could create a perfectly like FM tool.
Think about it :
-we already have the WYSWYG interface, natively with RunRev : we already move, drag and drop objects (buttons, fields etc.) onto a "blank page", the card

-for that matter, it's piece of cake to create "layout" (in FM sense). A layout is just a set of objects with fixed location, that would be saved in one file. Everytime you display a layout, you load a set of objects, with their descriptions, properties and location.

-we have the DB connexions and queries capabilities

-we can be single or multiple users (i use intensively RunREv + MySQL it's great, with native drivers. Or through the ODBC driver, for MSSQL database)

-we already have (of course !) a scripting system ! Think about : it would be very easy to mimick the -poor- "script" system of FM : the user could create and attach functions and commands scripts to his objects.

-we are Windows and MacOS

What we really need in order to increase the "appeal" of RunRev as DB front-end (and this is a key market, really, for businesses) :
-revamp the DB commands and functions (it's mixed up, old ones with new ones)

What do we miss ?
-a system to handle searches like FM : you start from the input layout, you go to "search mode" : you keep the same layout.
-a system that would manage DB relationships and the writing of SQL queries (FM does it very well, in a smart way)

A RunRev star developper (which I'm clearly not) could do that finger in the nose, I believe.

I think we are many to do some "lobbying" with RunRev, for them to take that direction... And who knows, 2010 could be the year of reward for us. Maybe RunRev is working on it. I hope.

You beat me to the punch with this request. This would be a fantastic native feature; although, like bangkok said, you can create your own functions in Rev.

I am a recent Revolution user, having just purchased Studio the end of January. I decided on Revolution over other tools (open source included), because of its rapid development paradigm and royalty-free application distribution scheme.

One mistake I initially made when evaluating Revolution was to only read the User Manual. Don't go that path -- just download the FREE revMedia and play with it.

Furthermore, revTalk -- Revolution's programming language -- is a powerful development language unlike FM. It even has bit manipulation functions. Be prepared for a steep learning curve, though.

But, remember this: Revolution is not a DBMS -- you connect to whatever supported database system you want. Consequently, since Revolution is not a DBMS, that means that you don't create reports in a fashion that one would be accustomed to doing if using FM or another system. Fortunately, that is not really a problem, since there is a 3rd-party report generator available.

Best thing is: people here are very helpful and friendly!

If you are interested in going from Filemaker to Rev, there is an interesting product for you:

http://www.fmpromigrator.com/products/f ... index.html

Glad to hear that others like the idea of field input validation.

Rather than mentioning certain RDMS, perhaps RealBasic would have been a more appropriate contrast. Although I haven't used it since Mac OS9 days I believe it has both TextField format and TextField mask properties which come someway towards what I would love to see in runrev.

Poor old Filemaker always gets a bashing but for all its limitations it does do somethings right and if rev implemented the field input options in a nice gui fashion like Filemakers then the World’s Easiest Programming Language would get even better.

Best Regards

Chris

If you can spare a moment to outline those masks specs I'll see about a behavior script to make 'em work. Deal?

You mean the Realbasic (now Real Studio) masks? See attached PDF which was extracted from the user guide and also refer to the following: http://realbasic.tutspolis.com/classes/ ... d-control/

I know that rev can do all this stuff, its just that it is in no way as convenient to implement in rev as it is in some other software. I just feel it would be a very nice feature set to have especially for users who work mostly with business applications or come from a database background.

Best Regards

Chris

Oops, PDF files not allowed, here is the missing attachment from my last post zipped up.

Chris

Thanks for the info. This is such a common need that I've proposed it as a project for the Rev Interoperability Group:
http://tech.groups.yahoo.com/group/revInterop/

Ideally we could all contribute to an MIT-licensed open source library or behavior that everyone can use.

The discussion here is very reminiscent to my programming experience in Tcl/Tk. We often times discussed on how to forage for code. It was acceptable then with what we had but it's already 2010. Why go foraging in the age modern domestication and mass production. It is very dissapoingting to know that RunRev doesn't even have this very basic essentials when all modern RAD tools have this. I came here because of their ad of being 10x productive using Rev. So far I can't see that. Recommending this for company use would be a hard sell.

I guess it depends on the company, and the specifics of the task at hand.

For many, writing a few lines of code to filter field input is more than offset by the ROI advantages of such a high-level language so tightly coupled with a well-defined and flexible object model that never eats up your day with the productivity loss of compile-runtime cycles.

When the RIP working group delivers a behavior script for this it'll be as easy as with any other system, requiring you to just set a property without writing a single line of code.

But as a volunteer FOSS effort (read, "we're donating non-billable time"), that won't likely happen right away.

In the meantime, "foraging" happens in every language, even in the 21st century: none of them have a BuildMyApplication command.

Every language does some things well, and other things weakly. Rev's chunk expressions make simple work of even complex string parsing, something a great many popular languages are relatively weak at. But Rev's field masking is weak, something others have in their favor. I have yet to find the perfect language which has everything. For every weakness in a language, one will find themselves foraging for code.

When foraging for RevTalk, you have us to do some of your work for you. Tell us what field mask is holding you up, and we'll write the handler to do that and you can move on to more interesting tasks.

Very well said. If not for the very friendly and active forum I would have looked somewhere else. I have progressed considerably well from a confused newbie coming from a different programming paradigm to an adapting newbie.

[quote="gwbasic" I have progressed considerably well from a confused newbie coming from a different programming paradigm to an adapting newbie.[/quote]
I like that phrase, "adapting newbie". We're all adapting newbies at one thing or another. I'll be using that one often.