Hi! The title says it all... I would like to know why you chose FileMaker over VB/C#.NET, C/C++ or any other (wich are really programming language). I have to work with FileMaker since the company I work for bought another company that already had a software deveopped in FileMaker. Having work with C, C# C++ .NET, PHP, ActionScript ... I find that FileMaker is so limited, it's a pain in the ass when it comes to something a little bit complex (I haven't work with the version 8 though, seems like it now has variables, finally...). I mean nothing is dynamic, and blah... Anyway, that is not a FM Hater thread, but rather a thread to understand why is FM used...

Thank you!

You cant compare FileMaker to a true programming language because FileMaker is not meant for programming. It is an all in one solution for creating databases relatively quickly and easily. This being said, FileMaker is a database. It is not C, Perl, Java, etc.

Now the great thing about FileMaker, especially now in 7/8, is that you can create some pretty powerful databases with a front end without having to create them seperately. With 7/8 it has becomes more 'programmer friendly' but it is still in essence a database with an included front end.

Sure there are limitations to FileMaker, but it has comes a long way and its so exciting now developing solutions with the new power of it. You can create powerful solutions quickly.

Just my :twocents:

well thanks, that explains a lot to me.

I find that FileMaker is so limited, it's a pain in the ass when it comes to something a little bit complex

I believe that is an extreme oversimplification. I have designed immensely complex systems, essentially automating the workflow of entire companies, in FileMaker. Are you implying that the languages you list in your question are NOT a pain in the ass? I find developing in FileMaker to be infinitely less agonizing than developing in, say, C++.

FileMaker's greatest forte is it's ease of use. I've never been able to create such stable, useful and powerful solutions with so little effort in any other environment. Granted, it has it's weaknesses, but so does every other development environment out there.

And I challenge you to provide some backup to the statement that FileMaker is "limited". What, exactly, are you referring to, and what are you comparing it to?

-Stanley

Well, I have to say that I only worked with FM 5 & 6. So maybe that has been resolved in 7 and 8, but, first off, there is no VARIABLES... there is no where you can type code... you could be one-armed tech and be able to work just as someone with 2 hands.. its only mouse clicks....

but anyway, I think version 8 has much more than I am actually aware of.. thank you

Filemaker is not programming ...it's developement!

The urge to script extensively ...is usually down to getting the relations wrong. (unnormalized datastructure)

BTW provides FM8 variables, scriptparamters, scriptexitparamters + if you need a special function, do you brew your own plugin in c++ or design a Custom Function.

--sd

Don't forget that with fm it's much easier to make something that works on both mac and windows than it is with C/C++, where you have to learn the API for each platform as well as the language itself, and then maintain two separate sources.

Even other cross-platform programming environments like RealBasic, Servoy, 4D etc., have a significantly steeper learning curve than FMP.

And I challenge you to provide some backup to the statement that FileMaker is "limited". What, exactly, are you referring to, and what are you comparing it to?

-Stanley

That's easy enough and we don't even have to conpare with the real programming environments: look at how Access has both a ScriptMaker (point & click Macro builder) and a full blown free-text code writer (VBA modules). Through VBA you have access to all of the underlying OS, can talk directly and invisibly to other applications (Word, Excel, MapPoint, ...), connect to the internet, do SQL queries,...It's one area where Access is really good at.

FileMaker to this day still has no "perform VBscript" equivalent to the "perform AppleScript" script step. There are a lot of frustrating hoops to jump through to get FileMaker to talk to another app or the OS and return a result to FileMaker.

Yes, we occassionally do have to jump thru hoops, but not as often as in the past. Yes, Filemaker has limited hooks into the operating system and other languages. I've gotten around most of these by using WinBatch. And yes, we need to buy plugins for doing things that Filemaker should do natively (like dialogs and file manipulation). But development is fast, and debugging is easy.

I wrote for many, many years in Fortran (and a little PL-1, Dartmouth Basic, Pascal, SQL-DS). It's a hell of a lot faster and easier in Filemaker.

And as for Filemaker not really being programming, I couldn't disagree more with Soren. It's just not nearly as complex, tedious and demanding as C++.

Steve

Filemaker has limited hooks into the operating system and other languages. I've gotten around most of these by using WinBatch.

There's nothing you can do with WinBatch that you can't do with VBscript (a lot more efficient at that). And VBscript being native to Windows means it is free and already installed. So you don't need to purchase WinBatch or even install the free AutoIT. That's not the point. The point is that it is too hard to automate the OS or another app from inside FM *and* get the result of whatever you're doing back into FM.

I've demonstrated the hoops we have to go through at the last 2 FileMaker Developer Conferences. It's not impossible and it does not make FileMaker a bad platform. But it does mean FileMaker is limited in that respect.

WinBatch has an easier learning curve than VB, and probably requires less code to accomplish the same task. While it's not the only approach to handling things that Filemaker can't, it does make automating some tasks pretty easy. My only point was that there are usually ways around things that FM can't do.

Filemaker isn't perfect, and its support of the developer community is generally abominable. However, I still like developing in it.

Steve

There's nothing you can do with WinBatch

Winbatchers brag about catching floating pallets etc. ...this within reach as well??

--sd

WinBatch has an easier learning curve than VB

I was talking about VBscript, not VB. Different thing altogether. And not much of a learning curve since your Windows machine has thousands of examples already on it. Examples actually for just about anything you'll ever want to do. All for free That's what I've been demonstrating at the last 2 Devcons and more recently at the FSA conference in Germany. It really is easy, and did I mention it's free?

Another argument: look at your average compiled WinBatch size and compare it to the size of a VBscript that does the same thing. It'll be in the order of magnitude of 10k or less for the VBscript to 1MB for the compiled Winbatch. I've replaced many WinBatch processes for clients, the VBscripts always run faster.

While it's not the only approach to handling things that Filemaker can't, it does make automating some tasks pretty easy.

One thing you can't do with Winbatch and that you can do with VBscript is dynamically generate the code *inside* FM then output, execute and delete it so that no traces of it exist outside FM. Winbatch would require command line parameters or something of the sort.

Don't get me wrong, I still like working in FM too, but let's not be blind for the things it does not do very well. In fact, make sure to put in feature requests for the things you want instead of living with workarounds:

http://www.filemaker.com/company/product/feature_request.html

Not sure what you mean by "catching palettes"...

Hi Wim

Floating pallets in graphic design tools automation, is something a local importer of WinBatch was particular fond of being able to catch and manipulate.

When thinking about it, say Photoshop is the floating pallets just one of the ways to interact, while doing it thru the menu's is another one, only poorly designed tools doesn't provide more than one way to address the same task (...should it be Filemaker before 8 : )

But say you hypothetically are in an app that only provides floating pallets, as the way you manipulate your data???

--sd

At the time I started using FileMaker the only "other" program that resided on my computer was HyperCard I started a solution on both and compaired them each. In some respects HyperCard seemed easier.

But after a short amount of time I just fell in love with FileMaker's abilities. So I stuck with it. Shortly after I really got involved in Graphic Arts designing stationery and business cards. At the time I just could not afford to shell out for Publish It Easy or Aldus Page Maker and in my wildest dreams could I ever afford Quark Express. So I used what I had — FileMaker.

I was actually using FileMaker's layout tools as a full blown page layout program. And for the time it did very well. Having designed a several hundred newsletters and business stationery. Somewhere along the way I taught myself the other half — the database side of things.

Then along came an upgrade. I "borrowed" what funds I could from mom and went forward in my education of FileMaker. In that day Claris tech support calls were free. I remembered spending countles hours on the phone (long distance) talking to the experts in tech support. It was a different day when we had a problem or coudln't find a way to do something I would call them up and we would sit for hours and build the solution on the phone together he would recreate what I had done and we would test out theories or ideas together. On one occasion he sent me a disk (800K Floppy disk) of the file we worked on I got it a few days latter with the "Claris" label on it.

As a memeber of our local Mac user group I mentioned I knew FileMaker and so I was assigned a night to give a demonstration. I remember we had a full house and I got to present my demonstration on the "big" screen (In thoes days that was impressive). Everbody just simply was amazed at what FileMaker coud do and at this point it wasn't even relational.

At the next meeting I brought with me a flyer to purchase FileMaker along with my father's credit card processing machine and opened the invitation for the entire group to purchase FileMaker. Everybody purchased a copy. About a week later I had a box of about 20 paid copies of FileMaker to distrubte to the members of the usergroup. [smaller]If you are interested in joining a user group you have to check out http://www.fmpug.com[/smaller].

And I remembered at one point debating which program I should invest time in learing FileMaker or Hypercard. I am very glad I had chosen FileMaker.

Over the course of years I had wished for a resource to find other like me in there quest for expanding their FileMaker education. I was having that "Field of Dreams" moment "build it and they will come."

By dedication and a little hard work, here we are FM Forums. :yay:

FileMaker is for the idiots like me. Access, VB, Etc.and the like is like taking a tractor trailer to the grocery store to get a gallon of milk.

John

I'd like to add - idiots like me too . . .

Would it be possible to assume a history of mac exposures aided in the choice of FileMaker ?

I think I would be working - nay - 'thinking' very (un)differently if I started my computer career on a PC. Don’t get me wrong, 10 years as a graphic designer using macs, then 6 years as an Apple qualified tech, with the last two years learning and developing FileMaker on macs, most of my ‘frustration’ time is spent getting Macs and PCs to play nice together. The rest of my ‘frustration’ time is removing viruses and adware from friend’s PCs.

I recently had a discussion with an experienced VB developer, who's main advice was to get rid of the 'application' dependence of FileMaker, and have our database rebuilt in VB, and he mentioned that VB4 would do the job. He didn't feel the need to even look at our database before advising . . .

He also mentioned that we should get rid of our Macs while we were at it . . .