Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 7093 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I may be trying to do something that can't be done, but here goes:

I'm building a calendar interface that lets users select a date from a pop-up calendar window. Each date is a button. When pressing a date on the calendar, its value should be captured.

I have a layout of fields with Calculated results in them, arrayed like a calendar. This allows the user to scroll through months (a perpetual calendar).

For GUI reasons I want to turn each field into a BUTTON.

When clicked, the button should activate a script that gets the contents of the field corresponding to the button, sends it to a field and then closes the window.

This script should be generic, so that each field/button in the row can use the same script.

It seems to me that there should be an easy and obvious way to acheive this, but I haven't found it yet.

Any ideas?

Posted

Each button should have a script parameter assigned to it. Instead of getting the contents of the field corresponding to the button, get always the content of the first field, and add to it, e.g.:

Set Field [ gDateRegister ; first field + Get ( ScriptParameter ) ]

Posted

Comment -- thanks for the tip, the rant below applies to FM, not you.

The script parameter trick works, but it seems to be a kluge.

Here's why: I now have to set up 37 variants of the same button action, each with a script parameter. And the script parameter is equal to the existing field value!

If the button could retrieve the value of its field, then I wouldn't have to do that.

I run into this type of problem with FM every once in a while. Something that I think would be obvious and helpful doesn't seem to exist.

Is the idea of a self-referential button so strange that no one else ever needed it?

Posted

The button is in front of the field. When you click the button, it activates the button action, so your cursor never touches the field, so to speak, to identify it.

How do you recon 37 buttons? I'd think 7 should be enough, or - if you prefer the hard way - there need to be 42 of them.

Posted

Yeah, the button blocks the field. I just think we should be able to define it so that the button is the field, basically.

37 comes about like this. The calendar usees one layout to specify any possible month of any possible year.

The most numbers on a grid that you'd need is 31. The highest start position for the first date is 7. The maximum possible end position for that month is 37, since the range 7-37 is the same as the range 1-31, just shifted by 6.

MonthStart = Day of week of 1st day of Month

MonthStart <= 7

MaxDaysinMonth = 31

MonthEnd = MonthStart + MaxDaysInMonth - 1

For June 2005

MonthStart = 4 (Wednesday)

MaxDaysInMonth = 30

MonthEnd = 33 (4 + 30 - 1)

Not sure how to do that in 7 fields. Don't need 42 since the latest possible end day is a Monday, fields 38-42 would always be blank.

cal.png

This topic is 7093 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.