stefangs

Members
  • Content count

    359
  • Joined

  • Last visited

Community Reputation

0 Neutral

About stefangs

  • Rank
    member
  • Birthday 09/25/1959

Profile Information

  • Gender
    Not Telling
  • Location
    Germany

FIleMaker Profile

  • Profile Updated
    03/16/2017
  • FM Application
    13 Advanced
  • Platform
    Mac OS X Mavericks
  • Skill Level
    Intermediate
  1. Yes, I missed that at first. Thanks for pointing it out.
  2. From the link you posted: Important To ensure that merge values are displayed accurately, each record must be refreshed as it is being browsed, previewed, or printed. You can refresh records manually by, for example, creating a “Refresh” button that calls the Refresh Window script step, or automatically by creating a script that includes the Refresh Window script step. - I think a dedicated layout for even more than one language is not practical, because there are so many layouts as it is. Do you advise against the global field approach because global fields have a bad reputation in general when it comes to storing data? Thanks, Stefan
  3. Oh, now we have merge variables too! As cool as the feature is, it is a bit of a bummer that you have to refresh every time you view a record. Before I dive into this, it would be good to know if that isn't going to be a bad user experience (screen flickering for no apparent reason, or slowing down browsing). Have you seen something like this in action? Thanks for the link, Stefan PS, you second guessed me correct on the first part.
  4. Thanks Lee, I'm not quite ready for a subscription based product yet. But I know we all have to succumb to the pressure eventually. Too bad I missed the v.14 upgrade cycle. Are you saying that the layouts do not have field labels until you do a scripted navigation and at that point they become populated? And how do I put a variable on a layout?? I know you can't, but what is the string-holder then?
  5. I knew you would come up with something more complicated than global fields But seriously, why would variables be better? You'd still need to store the strings in fields, right?
  6. Ok, stuffing global fields with an initial script is something I understand ;-) That v.14 looks more tempting all the time. It's probably not available any longer, but I'll check the FM site. Thanks, Stefan
  7. Well actually I am, but I'm developing this on FMA 13. No, haven't thought about this. Actually, I haven't even used the button bar. Perhaps a good reason to try it. Thanks Stefan
  8. After my post from 2008: I gave up on localization, because the buttons on the dialog boxes couldn't be filled with custom text. Now that this is possible, I'm dabbling at this again and I have a question. For the dialog boxes, I've created a table with one record per dialog box. There's a field for the content and one each for up to three buttons. When clicking a button, I'm capturing two script parameters, one for the currently selected language and one for the ID of the proper dialog. This creates a key field and pulls out the proper text strings. This seems to work well so far (although I'm still at an early stage here). Now with field labels that strategy falls apart, because I can't create relationships like above. There are obviously many field labels and the only thing I can think of is to create a table with a ton of global fields that contain the text strings. That seems clunky and I wonder if there's a more elegant way. it would be ideal (and easier to manage) with something like I did with the dialog boxes, i.e. a table with one text string per record in every supported language. I can't think if a way to make that happen though. Any ideas? Thanks, Stefan
  9. Not that I haven't successfully used the & operator for the last 20 years. Don't know what I had been thinking (or drinking) when I posted that... But: LeftValues ( Get ( ScriptParameter ) ; 3 ) and the second part by = GetValue ( Get ( ScriptParameter ) ; 4 ) worked just fine and I would not have figured this out by myself. Thank you for your help and sorry for the late reply.
  10. Thanks Lee, I'll watch my step fron now on :-)
  11. Thanks, Stefan PS, sorry about the bad formatting in my response, don't see how to quote and preview around here any longer... and where's that blush emoticon anyway.
  12. Hi all, it's been a while... I'm trying to capture two script parameters by clicking a button. The first parameter is supposed to give me a key for looking up related line items by date, for example the first quarter of 2016, and I also want to capture this as a literal text. The script parameter I've attached to the button looks like this: "1|2016¶ 2|2016¶ 3|2016¶" & "1st quarter 2016" The problem is that the second line is interpreted as the second script parameter. How can I express it so that the entire block is interpreted as a single parameter and only the text blurb at the end is interpreted as the second parameter? Thanks, Stefan
  13. Comment, your template works perfectly. I must admit, however, that I just sort of copied the code. Can you tell me why you are referencing the file name in the cLabelsR field? It looks like the purpose of this field is to figure out how many currencies are used. Thanks much, Stefan
  14. Thanks so much for the template you sent me. It will take me a bit to absorb it, but I'm sure it will do. My idea above didn't sound that appealing to me, either! Stefan
  15. The totals should represent the total sales, but broken down by currency. This is what I had envisioned in the report: [Summary (by currency and product)] product qty currency price total ABC 3 USD 5 15 <- these are already summarized by product ID from several line items YDH 1 USD 10 10 ABC 2 EUR 8 16 [Trailing grand summary] Total USD: 25 Total EUR: 16 Instead, the trailing grand summary currently shows: Total: 41 I will find out about FastSummaries, don't know what that is. The calculation field method would probably work, too. How about a calculation field that would summarize all line items with the same currency based on a relationship. I think that would require one field per currency. Not as straight forward as a summary field. I don't expect more than 3 currencies. Thanks, Stefan