No, that's a dynamic Go To Object followed by a Set Field. It's a workaround, not the real thing. I can set field without the field being on the layout. I cannot do that with this technique.

OK, I know it's a work around, but its not huge... just one extra script step. I've been playin' in FM since 2.0... now those were work around days. :

Edited July 15, 200718 yr by Guest

Well, no it still pretty annoying. It may be one extra script step but remember that you also have to a) have the field on the layout and : give every field you want to set an additional object name.... Its really almost the same as looping through all the fields on the layout and setting the field that evaluates to the correct name.

Well, I would think it wouldn't be too hard to make a plug-in that does a dynamic SetField by using the ExecuteSQL() API and using an UPDATE statement. That would only allow setting fields in the current record though, as the SQL code can't "see" the relationship graph - still, it would be better than nothing.

Hmmm, true that.

Yeah, I tried it out, and it seems to work out fine.

Plug-in developers, please feel free to borrow the following plug-in idea:

A dynamic set-field as an external function:

SPF_SetField( tableName, fieldName, recordId, textData )

I slapped togather a quick one like this:

FMX_PROC(fmx::errcode) SPF_SetField(short funcId, const fmx::ExprEnv& environment, const fmx::DataVect& dataVect, fmx::Data& result)

{

    fmx::errcode        err = 0;



	const fmx::Text&	      tableName = dataVect.AtAsText(0);

	 const fmx::Text&        fieldName = dataVect.AtAsText(1);

	 const fmx::Text&	      rowId = dataVect.AtAsText(2);



	 // Just use text for this example

	 const fmx::Text&        textToSet = dataVect.AtAsText(3);



	fmx::TextAutoPtr    updateText;

	fmx::TextAutoPtr    tempText;

	

	updateText->Assign("update ");

	updateText->AppendText(tableName);



	tempText->Assign(" set ");

	updateText->AppendText(*tempText);

	

	updateText->AppendText(fieldName);

	

	tempText->Assign(" = '");

	updateText->AppendText(*tempText);



	updateText->AppendText(textToSet);

	

	tempText->Assign("' where rowId = ");

	updateText->AppendText(*tempText);

	

	updateText->AppendText(rowId);

	

	err = environment.ExecuteSQL( *updateText, result, 0, 0 );

 

    return err;

}

See that code actually makes perfect sense, why can't the FM examples ever be decent. Then again the last time I gave plugin development a shot I had no clue what OOP was.

Shawn, if you could, how would that example look if you wanted to make it server side?

Edited July 16, 200718 yr by Guest

I would think this function would work server-side as-is. Whether it is allowed be run on the server is decided by settings when you register the function (which I didn't show above).

All it uses is the ExecuteSql() call, which is the internal 'experimental' SQL API, (which does not use the FM ODBC driver), so it should be able to always work on either the server or a client.

But, I only tested this as a client side plug-in, I don't run a server.

Also, any users of this plug-in code should realize this sort of side-effect action is inherently "unexpected" by FM Pro, and I would suggest running this calculation only from a script - I tried putting one into a calculation in the field definitions and it came back with a record locking error. (it was the same table being accessed the the calculation was defined in).

Shawn,

come back !

THE SHADOW FOR PRESIDENT !

Edited July 16, 200718 yr by Guest

Awesome, I think I remember some of the function registration so might play around with the Idea and see how it works out.

Cheers again Shawn.

1. No Script Triggering via Enter, Exit field events. Don't even get me started with this issue.

4. No Script Triggering via Enter, Exit field events. Don't even get me started with this issue. Ooops, already said that ;-) I'm sure I'm not the only extremely frustrated by this. This feature should have been in version 7.0! Is FileMaker really listening to developers? If I'm not mistaken, doesn't M$ ACCE$$ have the ability for field level script triggering? I was really hopeful that with FM 9, we developers would finally get this feature (NATIVE) to FM without the use of external plug-ins. When is version 10 coming out again?

8. Guess what, no keyboard shortcut for to get to the Custom Function dialog box (grrrrr).

9. While we're at it, there is no keyboard shortcut to the Value Lists dialog box (grrrr x 2). I'd really like to see this happen sometime soon.

1. & 4. You can trigger scripts when entering a field, you set up the field to act as a button, which is done through "Button Setup" when right clicking (or control clicking for you Mac Heads)

8. & 9. You can create your own keyboard shortcuts for ANY menu option through Custom Menu Sets

both of the things I have just mentioned have been available in 8 and 8.5

8. & 9. You can create your own keyboard shortcuts for ANY menu option through Custom Menu Sets

Unfortunately, Custom Function menu is not one of those options :

Unfortunately, Custom Function menu is not one of those options :

lawl

With Mac OS X, you can set your own shortcuts from the keyboard pref pane.

Takes some time to set up, but very handy.

1. & 4. You can trigger scripts when entering a field, you set up the field to act as a button, which is done through "Button Setup" when right clicking (or control clicking for you Mac Heads)

While this is useful in rare circumstances in some work around, in most cases its not workable, especially when the user is tabbing through the fields and suddenly they get to a button that looks like a field that they have to hit enter to get into - Its 2007, and the primary reason we want these triggers is not for "on field enter" but more like onchange, onexit etc.