Need a Day value list based on Month. Any ideas?

[PaddyO]

Hi,

First off, this is for an IWP solution...

Here's the problem.

I have a user defined "Find" script in which the user is first taken to a layout to set the date range in a couple of Global fields. (Thank you to Stuart, Mr. Vodka and many others for that help!)

Then the user advances to the next layout, the search criteria window. (this allows the setField to calc the date range and plug it into the date to search window.)

After plugging in the rest of the search criteria the user clicks the "find" button and advances to the list view with the found record set.

Everything is beautiful, BUT!

If the user plugs in an invalid date such as 11/31/2006 there is an error. Easy enough, right? I'll just capture the error in the gLastError field, redirect the user and handle it that way.

Well, there is an error code for virtually everything BUT this error. No Kidding! I checked my gLastError after the error (and much clicking to stop the error) and it reports a 101 (User Abort). The window that shows up says something like "The date must look like this "01/01/2000" and cannot exceede a year of 4000"

It doesn't actually produce an error code that I can see and it won't let you pass. Additionally, in IWP it breaks the whole process and leaves the user stranded.

SO, here's my question (finally...), how do I set up value lists on my date range layout to function by the month. Meaning, if the user selects a month of 11, the next window produces a value list with only 30 days? Or if the user selects February the value list that is displayed only goes up to 28? You get the idea.

I hope this isn't too much of a Russian novel for a simple question. I just notice a lot of people asking for more details when problem solving...

Regards,

PF

[LaRetta]

You can test that a valid date has been entered from within your script using not IsValid (globalDate). I would suggest against switching to splitting and searching for months etc. Dates are the best way to go. Your Value List theory - what happens on leap years? Simpler to use straight dates - always; much few resources and things that can go wrong.

[comment]

It does seem like a lot of resources for such a trivial task. But it's not THAT difficult to set it up correctly, leap years and all.

P.S. I have no idea if it works in IWP.

DaysInMonthVL.fp7.zip

[Søren Dyhr]

SO, here's my question (finally...), how do I set up value lists on my date range layout to function by the month. Meaning, if the user selects a month of 11, the next window produces a value list with only 30 days? Or if the user selects February the value list that is displayed only goes up to 28? You get the idea.

I have a different idea, although the hen/egg problem caused by the selfjoin needs a little scripting to behave, I have beyond that sifted weekends away as well - which weren't required but easily be the next question. I'm a firm believer of measures to abreviate dropdown list to a minimum.

I upload this template to get fresh ideas to improve some of the sillyness or obstracles expirienced during the developement.

--sd

DaysDropDown.zip

[comment]

I'm a firm believer of measures to abreviate dropdown list to a minimum.

I find the missing numbers are more confusing than it's worth (shaving 4/5 values off ~30).

Is it that difficult to have a pop-up calendar (the old-fashioned, hand-made kind) in IWP?

[Søren Dyhr]

No this user is on ver. 8.5 ...so it should be smooth sailing even under IWP ...however is there one snag to it with IWP and it's the problem that the webbrowser can't tell wich dateformat the OS behind uses and as default in IWP uses sundays as day one.

So the developer must if being in europe with his/her audience being there as well, seek shelter in a method like this:

http://www.spf-15.com/fmExamples/datePickWindow.fp7.sit

Modified to abide to the required dateformat.

--sd

[comment]

That's the kind I meant. If you can implement that in IWP, I think that's much better. You can avoid weekends by removing their buttons in the date picker.

BTW, regarding your file: if you're not using global fields (as required by OP), why do you need all that jazz with the script and the additional calc field? Why not make the repeating calculation stored, and base the value list on it directly?

Another point - what's the difference between:

Set Variable [ $Month; Value:test::entryMonth ]

Set Field [ test::entryMonth; $Month ]

and:

Set Field [ test::entryYear; test::entryYear ]

Are you making special efforts to make things more complicated than they need to be?

[PaddyO]

Hello all,

The samples and advice are beautiful!

Regarding the pop up menu for the calendar, it works in the local version but breaks on the IWP version. I think it messes with the script, especially on IE6 & 7. I think I might be able to write a book on the stuff that doesn't work in IWP. Which is not to say it is bad, don't get me wrong.

I like the pop up samples, I'll need to figure the way to incorporate them into my file properly. I'm still pretty new at this but I'm sure I can figure it out.

LaRetta, I would address it with a validation in my script but this is a strange error in that breaks the script and doesn't allow the script to get to the point of validation. There is a great chance that I am doing it wrong.

Is it a true statement that I will need to create a concat calc/field to re-group the data before handing the date over to the search date field?

Thank you again for all of your help!

If you want to take a look at the file in IWP here is the address...

http://71.222.71.38

Username: Admin

No Password

I know the UI is a bit of a mess but we're still in development here.

The date range is going to be used when the user clicks the REPORT button.

Søren made a good point in a different thread about attaching files rather than links, but I would rather you see the file in its intended UI mode.

[PaddyO]

Here are my user find scripts...

#For users to find records prior to viewing reports

Set Field [ Transactions::gLayoutNumber; Get ( LayoutNumber ) ]

Set Error Capture [ On ]

Allow User Abort [ On ]

#Turn User Abort OFF when script is tested!!

#Here is where the user goes to the Splash and sets the Date Range. A button there will resume the script

Go to Layout [ “adminSearchSplash” (Transactions) ]

Pause/Resume Script [ Indefinitely ]

Go to Layout [ “Search Window for Administrative Reporting” (Transactions) ]

Enter Find Mode [ ]

Perform Script [ “Set Date TEST” ]

Pause/Resume Script [ Indefinitely ]

Perform Find [ ]

#This is where error checking for the find begins

Set Field [ Transactions::gT_LastError; Get ( LastError ) ]

If [ Transactions::gT_LastError

[LaRetta]

One question ...

What if they leave one of the date fields blank? Do you want to produce an error or pre-fill the date with a base start (or end) date?

[PaddyO]

Good Question. I think I should set up the field this way:

Result is text

Auto Enter value (Made up date like 01/01/1990)

Allow override on data entry

select contents on entering field

Do you think that would work?

By the way, I tested the other date selection pop up methods posted here and they unfortunately don't work in IWP... So, I think this is what I will do,

gDateRangeStart will result in text (as mentioned above)

create cDateRangeStart results in date

Then script a validation on the text date before it goes to a SetField cDateRangeStart.

Would that do it. My hope is to produce an identifiable error code that I can deal with rather than what I have now.

Thank you for your help.

Edited January 1, 2007 by Guest
Typo

[Søren Dyhr]

I kind of agree with Comment here, approach the problem with whats availiable instead of kicking tumbleweed. Oregon is by and large at least 4 timeszones away from anyone that could dream of a different dateformat...

--sd

test2.zip

[LaRetta]

A User can STILL remove that date and insert an invalid one. And field-level validation is PIB even if NOT IWP.

[PaddyO]

Well, things are looking up.

Before when I had the drop down calendar activated it took a couple of clicks to get it to work properly. So, I tried it again with a mod to my script:

After

#Here is where the user goes to the Splash and sets the Date Range. A button there will resume the script

Go to Layout [ “adminSearchSplash” (Transactions) ]

I dropped in this:

Go to Field [select/perform; Transactions::g_T_Start Date]

So now when the user gets to the layout they only have to click into the date field and the calendar automatically pops up in Internet Explorer. (Firefox brings it up without having to click into the field...) I think that is pretty close for the moment.

LaRetta "PIB"? Don't know that one. Sorry. But, you are right, there is still a way to break down. The pop up calendar is merely risk management. I will include some isntructions on the date range entry layout for the user to use the pop up calendar. While my "debug" journal is seeing more and more checkmarks this will remain unchecked until I can finish slaying a couple of other dragons prior to the beta test launch.

I did test it in IWP just now and for some reason my error when the calendar is attached no longer breaks the script and leaves the user abandoned. I wish I could just capture that stinking error!

Søren, True about the Date Format. Gorwing up in a little Oregon town we thought Date Format choices were, Blind, Double or Chaperoned.

Thank you everyone for your help.

[LaRetta]

I've been too busy (here in Oregon) chasing off indians and hugging spotted owls to deal with date formats. We finally got running water and electricity this week! Now if only it would stop raining 20 inches a day ...

PIB (pain in butt) :wink2:

[PaddyO]

Truth be told, that last storm knocked me out of power for a week (central Willamette valley). Luckily our water supply is gravity fed from a spring up the hill. Too funny, huh? You thought you were joking about the running water and stuff!

Thanks again for all the help

[LaRetta]

Same location ... not joking about THAT part. :smirk:

[Søren Dyhr]

Are you making special efforts to make things more complicated than they need to be?

As usual am I trying to avoid globals, expirinces shared by Scott Love in "Using filemaker 8" have made me less expecting good behaviour from them, when using them under IWP, we have been chasing gremlins over this - so I was really surprised that he of all people say something similar.

--sd

[Lee Smith]

As usual am I trying to avoid globals, I was really surprised that he of all people say something similar.

--sd

I think it is all part of the Global Warming. ???

[Søren Dyhr]

Ha! Yes even Gore must admit that sometimes isn't two independent journalistic sources enought to prevent a scam! We might have made a simple error to make globals loose their value during what we expect is a single session ...we had this as a customer complaint not knowing why it occures!

On the other hand, why not play it safe and circumvent the use of globals by say cartheisan relations or userID as keys to genuine records a relation away.

--sd

[Søren Dyhr]

Blind, Double or Chaperoned

Nice one! What about deliberate misunderstandings, the bureaucratic disipline??

--sd

[PaddyO]

Dallas

[PaddyO]

So am I understanding that if I were a more advanced user I might consider using Variables in stead of Global fields?

Edited January 2, 2007 by Guest
Changed "parameters" to "variables"

[Søren Dyhr]

You have to at least consider how justified the use of a global field is. Here comes scope in as main topic. If you use it only in one script, might a local $variable be a more obvious choise, while the transfere of some data from script to script might be better dealt with as a script paramter/result

However, since you're working with a tool neither providing debugger nor dataviewer, will you probably be better off seeing partial processing via global fields during the developent ...but as soon as things are rock solid, should you change into $variables and script paramters and only consider $$varibales as a quick fix.

http://discuss.joelonsoftware.com/default.asp?design.4.249182.18

--sd

[comment]

From the original post:

the user is first taken to a layout to set the date range in a couple of Global fields.

It's not possible for a user to enter data directly into a variable, so global fields are inevitable in this situation.

[PaddyO]

Søren,

Thank you. I see that in time the globals can produce some troubles. I hope to be moving up in the development cycle and as such, begin using safer development practices.

[Søren Dyhr]

Alright I've taken a steb backwards to get a fuller picture of what you try to achieve, and the entire thread seems to be dealing with how to avoid catching errormessages and acting upon them.

What if we let the user input something in the vicinity of what they wish to, what does it matter if the user are in doubt how many days a certain month has?

The way I have chosen to solve the matter is to let the user input a pair of textstrings and then does calc'fields take care of making it into something sensible for a mutlicriteria relation instead of a straight forward search.

--sd

SansGlobals.zip

[PaddyO]

Søren,

That is pretty slick! I like it.

Also, It isn't that I don't want to act on the error message, it is that the error isn't producing a code that I can capture before it halts the script and leaves the IWP user stranded.

I have other areas in which I can successfully grab the error and direct the user to another layout to make a decision on how to proceed. (Custom messages don't work in IWP.)

I'm trying to act on the conventional wisdom that I must break everything to see what will happen and then program around those faults so the user never ends up stranded. I think it produces a great deal of overhead, especially in IWP, but that is what my client has chosen...

Without the the ability to show custom messages I am somewhat limited.

[Søren Dyhr]

Without the the ability to show custom messages I am somewhat limited.

Well you can pull up an extra window, via the webviewer and some java-scripting which I know nothing of except having seen one of those who hire me ...brag with it.

--sd