Jump to content

dazlunn

Members
  • Content Count

    36
  • Joined

  • Last visited

Community Reputation

0 Neutral

About dazlunn

  • Rank
    member
  1. You could use a calculation on the year the child was incepted versus the current year. It would look something like: Year(Get(CurrentDate)) - Year(student::startdate) e.g output: 2010-2008 = 2 = Grade2 student::startdate being whatever field you already use track when a student enters the system. This calc would be in your "Grade" field and should be unstored. Because this will result in a zero based list you may need to add +1 to the end so that the first year = 1, and not 0. ( Year(Get(CurrentDate)) - Year(student::startdate) ) +1 e.g. output:
  2. I installed a new Java release today and few Windows updates and now FMPA10 won't boot up, I was wondering if anybody has encountered the same issue?
  3. I'm looking for some logical insight into "when" to deploy the separation model. I am working on a new project which combines 3 existing FM systems (just the functionality not the actual systems) and we are writing the 'new' system from scratch. This is going to be the largest data store I have ever worked with, in terms of population density of records (as opposed to number of tables). I typically work on smaller systems in general. We are just at the pencil/paper stage at the moment but approximately there will be around 25-30 base tables (maximum) but at least 3 tables will h
  4. Whenever you use tabs to display fields and data, the fields must be enclosed totally within the boundary of the main tab panel box. What you are in effect attempting to do is use the tab panel as a navigation object which is not its primary function. When you see what appears to be tabs on list views in other developers' solutions you are actually seeing buttons with navigation scripts that have been created to give the illusion of tabs. What the 'illusion tabs' are doing is simply switching between layouts. Alternatively, you could insert a portal and place that within the bou
  5. You would perhaps be better to use a global Date field rather than a calculation field in your circumstance. You can then use the 'Setfield' script function to update the field with the current date from a simple button, or in your startup script (if you have one). Setfield Value: Get(CurrentDate) Since you alluded to doing this by script I assume you would understand this?...
  6. Ender, Only noticed your reply last night whilst scanning thru my old posts and I hadn't replied so... Your reply made me question myself, so I tried to track back to where my 'Setfield in Find Mode-phobia' came from and I just can't determine it, only thing I can think of is that I did use it a few times way-way back with scripted date finds and had a few problems. But I just tried it in many instances today and all work fine!! AAaahhh... and I'm really such a tenacious so and so! and that is just sooooo basic too... Oh man, my pride is really hurting now.. woe woe woe.
  7. Hi Gene, I don't have a direct answer, but why are you using 2 sets of 'almost' identical data?? Surely that is defeating the objective of having centralised data? Ok there could be times when this is necessary, I suppose (although non spring to mind)... sounds like you are using one table as a master and the other as permutations of the master data, but why can't you build this into the same table? You are going to run into some serious issues by trying to use custom serialisation, it's not a sound way to build a solution, you should try to consolidate the table into a single
  8. Hack, You need a Find Request for each item you want to find. In Find Mode place "Otago" in the first find request, then go to Requests menu and "Add New Request".. in this new request type in "Auckland" (or whatever). Add a new request for each item you want. Learn the manual method first then this will help you with writing a scripted version..
  9. Hi Stuart, I have had a similar problem on an old system I wrote ages ago, your "isthisjustbetter" is pretty much how I solved the problem back then but I was unhappy with it as a fix.. for the same reason you give. I would like to have a go at revisiting this, so could you tell me if the value list items appear as they will in the finished article... i.e. Value1, Value2... or is this dummy info you've used to give clarity to the problem?
  10. Yes, true - my articulation was not very clear... I should have said that it's not what 'I' normally use, have had querky experiences previously and try to avoid this method... I was struggling to see where the scripts were falling down, other than field types... Sorry!
  11. On your second script I notice that you are using setfield in conjunction with find mode... Setfield is used normally to change the contents of a field and not for find criteria. Try using Insert Calculated Result instead and see if that works...
  12. Quote: I meant that I set the script variables to be local global fields. Can you explain this a bit clearer, I don't follow...?
  13. Do you actually mean 'displaying related records' in the adjacent portal? or highlighting? Two quite different meanings inferred... Let's say the left portal is 'library books' and the right portal is 'readers', when you click on a portal book (on the left) then the right portal would show who's read it? Am I close?
  14. What kind of fields are the 'open' & 'closed' fields that the script is trying to set? It looks to me like it's a summary or sum() field that calcs: (no. records opened) vs. (no. closed) If so, you can't use setfield on this type of field. When you say you tried global fields also, did you mean you just changed the calc fields to global storage? Or are the field types text, number etc??
  15. Hi, There are two functions that you can use, one for privilege sets, one for account name... below: Get(PrivilegeSetName) Get(AccountName) You can use these to conditionally go to the layout you prescribe based on the result of an IF[] calc. HTH
×
×
  • Create New...

Important Information

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