stefangs

Members
  • Content count

    362
  • 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. Just a push really... anyone want to try my template and comment on it? Ideas for improving it? Would be happy to get some feedback! Thanks, Stefan
  2. I'll come back to this line in 2018 It is seriously above my level, but I'm happy to have something to chew on! Thanks, Stefan
  3. Ok, so I put together a template that shows one strategy of going about my localization project. I have included the dialog boxes also, just to show you that part, too. I have used global variables to store the strings which would require an intial script to populate them. This isn't included in the template. Hope that some of you can take a minute to check this out. It works, but I don't know how clunky it will get once I add probably about 100 dialogs and perhaps 200 field labels. @comment: I'd be curious to hear your comments, mostly because I don't quite see the advantage of the variables vs. global fields. Thanks, Stefan Language_demo.zip
  4. Yes, I missed that at first. Thanks for pointing it out.
  5. 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
  6. 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.
  7. 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?
  8. 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?
  9. 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
  10. 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
  11. 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
  12. 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.
  13. Thanks Lee, I'll watch my step fron now on :-)
  14. 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.
  15. 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