As the person originating this thread and considering moving from Filemaker to RR I am aware that I must recreate my interface and set about choosing, learning an SQL type database system.
My concerns in contemplating this move are:
1. Can I reproduce enough of my interface to satisfy my client?
Probably more so.
User interfaces are primarily event-driven, responsing to user gestures on controls.
FMP is pretty much limited to two events: mouseUp on a button and menuPick in a menu item.
In FMP you have only one modifiable menu, so if you need a custom file import routine you can't put it in the File menu where a user would expect it, but must place it in the Scripts menu.
Rev has dozens of events to respond to, so the flexibility is almost mind-boggling when coming from FMP. For example, it's quite common for a double-click event in a list to trigger the default action, usually a button in the layout. This triggering is not possible in FMP, but is a trival extra to include in Rev:
on mouseDoubleUp
click at the loc of btn 1
end mouseDoubleUpOther advantages I like are the flexibility and ease of parsing using chunk expressions ("get word 1 of line 2 of gMyGlobalVar"), and being able to use true global variables rather than needing to add fields to a table, and many others....
2. Can I solve my speed bottlenecks? This is not unrelated to (1) as, if the client sees big speed improvements here, he is likely to be tolerant of interface differences. In this respect, I think the possibilities look very good.
I would be surprised if you find areas where FMP's DB outperforms the highly-optimized MySQL engine, or its UI outperforms Rev.
And I don't know if this is now and option in FMP7, but in previous versions windows were not double-buffered, which gave layouts a bit of a clumsy effect during redraw (akin to Mac Classic dialogs, in which controls are drawn directly to screen one at a time rather than into a buffer and having the buffer copied over in one move).
Rev allows you control over double-buffering (just set the alwaysBuffer of a stack to true), making for a very smooth, modern-feeling redraw.
3. Is there anything I cannot replicate with enough effort?
I've come across nothing I can't deliver more gracefully in Rev. Some things are easier than others, as it true with any system, but overall the balance I find with Rev is quite favorable.
I still like FMP for internal databases -- my billing system is built in FMP (though I'm slowly migrating portions to Rev). FMP is a great way to put together workgroup solutions really quickly with minimal effort.
But for client deliverables, though I like to include FMP in our tools evaluation matrix at the outset of a new project, it usually gets booted early on because of its minimal UI flexibility.
4. After the initial learning curve will my productivity be greater than with competing tools?
In my experience, yes. As a true scripting language you'll get farther than with the confines of FMP's point-and-click "scripting", and as a very-high-level language you'll get more done per line than in most other languages.
5. As RR's scripting is proprietary it is most critical the company stick around so my investment in time will not be lost. I cannot over emphasise how important the activity and supportiveness of this list is in providing reassurance.
The Rev engine was acquired by Runtime Revolution Ltd. last year, after having been in the market for 13 years under its former name, MetaCard. With almost no marketing, MetaCard Corp. was able to keep expanding the engine and the number of supported platforms without difficulty, and with Runtime Revolution Ltd's strong marketing efforts (they just won a MacEddy for v2.2) there should be no reason for this growth to slow down.
Of course, if you've been in the business as long as I have you know that products come and go, even from big companies like Oracle and Sybase. But enough people have enough invested in the engine and it has a sufficiently strong and well-demonstrated value proposition that I have confidence in it being around for many years to come.
MySQL, of course, looks like it's going to be here a very, very long time.
The potential benefits of the effort are large. If I take on the problems I have a solution that I own i.e. no runtime licences, that I can sculpt in myriad fashions not available in FM. I have data/interface separation.
Amen. De-coupling UI, logic, and data carries tremendous value, and is easy to do with Rev.
In a way, Rev could be said to be far closer to 4D than to FMP, as 4D provides a rich programming language and event-driven UIs. But even then, IMNSHO comparisons favor Rev's simpler language and greater variety of supported platforms, not to mention the strength of relying on MySQL for storage and retrieval, which is fast becoming a de-facto standard.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
