FMPA Runtimes, Activex & More

[Jorge Biquez]

Hello all.

I hope this message does not sound too stupid because of the kind of
questions. Here we go.

1) Any comments based on experience about working with FMPA or FMP
and calls or exchange of information with other languages and
applications?. As and Example, Activex. I see that the documentation
on FMPA 8.0 about Activex is very short. I do not know if that
changes with version 9.

2) I know that's the way FMPA runtimes work and that for FM is their
strategy of business. But, is there a way, not directly I guess, that
a runtime application of FMPA can share, update information with
another applicattion running on FMP/FMPA/FMS ? What I have thought is
to see if I can export all the information needed to update and have
another application , maybe a VB exe or C exe running AS A CRON and
checking if there is new information (in the client side and on the
server or FMP application ) and do the exchange of it.
The thing here is that the runtime have to do that. Maybe a plug in?
no problem if a plug in helps (if it is not too expensive). The main
thing is that the clients will have to be using the runtime version
of FMPA because of costs.

Thanks in advance for all the comments and I'm sorry to those that
could think these are question that are off topic.

Take care

Jorge Biquez

[Jonathan Fletcher]

Jorge,

Don't know ActiveX. Not gonna go there.

As to your second question, if the clients can see a copy of FMP, why  
not simply use Instant Web Publishing? It limits the interface, and  
you have to design your layouts and scripts with more care, but it is  
quite powerful.

Yes, you can do exports and imports as well, if that will get you all  
you need. You can also use something like the FTPit plug-in (which  
also works with runtimes) to send data to a central location if you  
are working with multiple sites.

j.


On Jul 4, 2008, at 11:15 PM, Jorge Biquez wrote:

> Hello all.
>
> I hope this message does not sound too stupid because of the kind of  
> questions. Here we go.
>
> 1) Any comments based on experience about working with FMPA or FMP  
> and calls or exchange of information with other languages and  
> applications?. As and Example, Activex. I see that the documentation  
> on FMPA 8.0 about Activex is very short. I do not know if that  
> changes with version 9.
>
> 2) I know that's the way FMPA runtimes work and that for FM is their  
> strategy of business. But, is there a way, not directly I guess,  
> that a runtime application of FMPA can share, update information  
> with another applicattion running on FMP/FMPA/FMS ? What I have  
> thought is to see if I can export all the information needed to  
> update and have another application , maybe a VB exe or C exe  
> running AS A CRON and checking if there is new information (in the  
> client side and on the server or FMP application ) and do the  
> exchange of it.
> The thing here is that the runtime have to do that. Maybe a plug in?  
> no problem if a plug in helps (if it is not too expensive). The main  
> thing is that the clients will have to be using the runtime version  
> of FMPA because of costs.
>
> Thanks in advance for all the comments and I'm sorry to those that  
> could think these are question that are off topic.
>
> Take care
>
> Jorge Biquez

--
Jonathan Fletcher
[hidden email]
Project Foreman
NewMedia Construction Co.

[Geoff Graham]

On Jul 4, 2008, at 11:15 PM, Jorge Biquez wrote:

>  What I have thought is to see if I can export all the information  
> needed to update and have another application , maybe a VB exe or C  
> exe running AS A CRON and checking if there is new information (in  
> the client side and on the server or FMP application ) and do the  
> exchange of it.
> The thing here is that the runtime have to do that. Maybe a plug in?  
> no problem if a plug in helps (if it is not too expensive). The main  
> thing is that the clients will have to be using the runtime version  
> of FMPA because of costs.

I think you're not going to get too many answers here because you/they  
are trying to deliberately violate the licensing agreement you agreed  
to when you installed Filemaker. You have hit upon the reason that  
runtimes are free (after purchase of Developer) and FileMaker clients  
are $250 a pop. For what it does, FileMaker is dirt cheap, and most of  
us here are big fans.

geoff

[Chuck Pelto]

Some javascript/style in this post has been disabled (why?)

Hi Geoff,

On Jul 7, 2008, at 4:20 PM, Geoff Graham wrote:

I think you're not going to get too many answers here because you/they are trying to deliberately violate the licensing agreement you agreed to when you installed Filemaker.

What part of the licensing agreement precludes runtime solutions communicating with each other via export-import activities?

You have hit upon the reason that runtimes are free (after purchase of Developer) and FileMaker clients are $250 a pop. For what it does, FileMaker is dirt cheap, and most of us here are big fans.

Yes. It's very good. However, think of an association of garden clubs scattered across a state. Little old ladies and their local organizations do not have a lot of money to spring for copies of FMP. $300 could be half of their annual budget. Runtime solutions that export membership data to the state-level organization would seem to be the answer.

Regards,

Chuck

[Geoff Graham]

Some javascript/style in this post has been disabled (why?)

On Jul 11, 2008, at 6:19 AM, Chuck Pelto wrote:

Hi Geoff,

On Jul 7, 2008, at 4:20 PM, Geoff Graham wrote:

I think you're not going to get too many answers here because you/they are trying to deliberately violate the licensing agreement you agreed to when you installed Filemaker.

What part of the licensing agreement precludes runtime solutions communicating with each other via export-import activities?

Nothing, but that's not what he proposed:

"... checking if there is new information (in the client side and on the server or FMP application ) and do the exchange of it."

I thought they were quite clear that you were not supposed to hack the runtime to pull or put data to filemaker server. But I could be wrong about that.

You have hit upon the reason that runtimes are free (after purchase of Developer) and FileMaker clients are $250 a pop. For what it does, FileMaker is dirt cheap, and most of us here are big fans.

Yes. It's very good. However, think of an association of garden clubs scattered across a state. Little old ladies and their local organizations do not have a lot of money to spring for copies of FMP. $300 could be half of their annual budget. Runtime solutions that export membership data to the state-level organization would seem to be the answer.

Regards,

Chuck

Agreed. And I wouldn't think such a setup would violate even the spirit of the FM license: Runtimes manipulate local data; and the central aggregation of that data is done with other tools, having nothing to do with Filemaker. It was the runtime using FMServer that got my attention.

geoff

[Chuck Pelto]

Some javascript/style in this post has been disabled (why?)

Hi Geoff,

On Jul 11, 2008, at 2:06 PM, Geoff Graham wrote:

Agreed. And I wouldn't think such a setup would violate even the spirit of the FM license: Runtimes manipulate local data; and the central aggregation of that data is done with other tools, having nothing to do with Filemaker. It was the runtime using FMServer that got my attention.

Ach tso!

It's the exchange of data to FMP Server that you suspect is a violation.

Well. If FMI has set things up that they consider the exchange of information, using export-import, a violation of their license......I think they have a serious problem with money-grubbing.

Regards,

Chuck