Jump to content

Charlie

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Charlie

  • Rank
    member
  1. There is a possible, but SHOCKINGLY inelegant solution, as long as you don't want the actual letters to curve. You could parse out your text into different fields and then place the fields into a circular type of layout: ******I**L ****W******B **R**********U J**************R (Yes, this is hideous, but.... And ignore the asterisks; when I tried to post this without them the whole thing collapsed.) I don't know if FM 5.5 allows free rotation of objects. If it does, you could probably approximate the effect you're trying to get. Well, enjoy. C
  2. All - Just curious if anyone has a nifty trick or other method for relating records based on inequalities. For example, if I wanted to relate record with field Date of value 10/15/01 to all other records that have a Date value of 10/15/01 or less. I've toyed with trying to have a secondary calc field that gets all Date values for records, but the concept becomes circular. I still need a way of isolating the records that are "less than" the record in question. I have certainly found solutions to this, but they always involve isolating records and using a running-total summary field. I was just wondering if anyone had some magic bullet that would allow a relationship-only solution. Many thanks. Charlie
  3. Fellow Hopers-for-Improvement: I'm back from the Sierra Leone hinterlands, at least for the next handful of days. I see no one has posted since October 15, so perhaps the discussion is falling off the rails? My suggestion is that we move the discussion to the Feature request forum and begin to discuss more specifically those bug-fixes and changes we think could make life better/more elegant for all. I think it's important that we discuss quite specifically *why* we would like a change and also to discuss how any changes proposed might *not* be a good thing. (I'm sure the FM squad must think quite carefully about how any changes might affect work that has gone into existing solutions.) We should also discuss what simple work-arounds exist so that we're not asking for frivolous or unnecessary functions or features. In due course we may begin to see how a comprehensive wish-list develops, perhaps organized by different functional areas. With luck the FM squad is monitoring this site. By setting forth arguments seriously and with due reflection, some changes may come about. What do you think about this idea? All the best, Charlie
  4. Kurt - Many thanks. I feel like I've just found a door behind a cabinet inside a house I've lived in for ten years. C
  5. All - I struggle with documenting my work all the time. With each new project I seem to change my own standards, conventions, etc., and I dont' usually have time to go back and make my old work better. At any rate, as was mentioned earlier in this thread, it would be exceptionally helpful (I think) if FM would include a "comments" box for every definable aspect of the program. e.g., in Define Fields, when you highlight a field, a text box at the bottom of the dialogue could show comments about the field. Same in Define Relationships, Define Value Lists, Scriptmaker, Layouts. I don't believe this would add a lot of overhead to the program because it's basically just text. The upside would be great though. Sometimes, going back over old work, even I can't figure out why I set something up a certain way, and if I have no external documentation, I have to scratch my head for a good while to figure out what I was thinking. God help those who come after me. Charlie
  6. All - I've sent a list of possible topics for discussion to Steve and to Moon. Is this the appropriate forum for discussing specifics, or should these things be picked up under the Feature Requests, etc. forum? Also, my list is pretty unpleasant to look at when I paste it into the window here. Are there any better ways of posting such a list? At any rate, here's a list to get the discussions going. I believe that some of these things have been addressed in 5.5, but I don't know the specifics. How we do this is definitely open to debate. Charlie (Crikey, I just saw this in Preview, and it's pretty ugly. Try not to hate me.) Category
  7. Kurt - I'll have to see what all this means, but my head is already thinking back to some very unpleasant work-arounds that I used last year on one project. It seems that you could use a multi-line field as a sort of repeating field in some cases, but still allow that field to be related. Are there limits to the number of "lines"? C
  8. Kurt - I'm a little slow on the uptake, but I didn't know you could do that. (Or if I knew it in the past, I'd forgotten it.) How does FM keep this straight??? Hard returns = consider text element to be different values for relationship?? I would have thought it was looking to match the entire field, not pieces of it. Crikey, it also works on the "right" side of the relationship, too. Where have I been all this time? Holy moly. Kind of opens up a lot of "options" in my mind. Thanks. Charlie [ October 12, 2001: Message edited by: Charlie ]
  9. Moon - My list is, ironically enough, in Excel. I will email it to you directly. If it looks like something that can be posted directly to this or another thread, you are probably more competent at doing than I. Here's to a fruitful discussion. Charlie
  10. All - I (sort of) started this, so I'll jump back in. I've been using Filemaker since 1991/2 (can't remember), back when it was flat and simple. Over time, the product, which I still love, has advanced rather nicely. The funny thing is, it's probably not possible for the FM design squad, whoever they may be, to anticipate everything. And if I look back over some of the weird stunts I've pulled with FM, there's probably no way they could have anticipated what the product was capable of. If you're like me, you've practically tortured the program into doing what you want. With each success, we cry "hooray!, and we explore a little further into what we can make it do. This leads to the inevitable "if only they would just add this one thing so that..." statement in your mind, and if you're like me, you pray the FM squad have the same thoughts. Nevertheless, there are a lot of aspects of FM that started out sort of crude, which we accepted back then. Nobody really thought of it as a "serious" database program, but we loved that we could use it and make it do things we wanted. It was obviously made FOR the layman, not a database programmer. Why FM hasn't addressed some of these design issues is a mystery to me. I don't think it would be that hard to clean up scripting, allow for saved views of field definitions (grouped to help you keep track of what's going on, etc.), rejigger the relationship dialogue box to allow a more visual representation of the relationships, allow comments to be added to things like field definitions, relationships, and list definitions, etc. These don't add complexity, they add clarity. These are things that all "users" would find helpful. The IT thing I think it's a very good thing that FM has gone far in "legitimizing itself" to the Microsoft/ODBC/SQL crowd. (I had a several-year battle with an IT department in the government over FM.) I'm not really qualified to talk about that aspect of the program, but I can easily see its importance. Ditto the web: I've only made one web-based solution, and that was using Tango and FM, not CDML or whatever. Again I'm not very qualified to comment on that. A little IT story: I'd written a huge, multi-table solution to handle grants for Americorps, a federal agency. I was working for peanuts (and here's the rub), I was clearly a layman when it comes to databases. The fact that I (the layman) was able to DO IT in Filemaker is what FM is all about. While I was gone for a few years in Africa, Americorps actually tried to replace what I had done, using Oracle, and they spent millions of dollars (no exaggeration) only to arrive at half a solution. The people who were using the new $2 million software declared it unusable, then coaxed me back and I redesigned the FM system to make it relational. I'd never used a relational database before, but FM made it a fairly easy proposition, at least conceptually. I think Americorps's total investment in the FM solution was something like $150,000 max. The IT people, who said about 100 times they were going to make us change to Access, despite the Oracle failure, finally gave in. Why? Not because they liked FM per se (they hate Apple in all forms), but because they knew they would have to spend another million or so redesigning what was working in FM so that they could run it in Access or SQL or Oracle or whatever. This is the real point here: a layman using only his wits, really looking at the task at hand, and using FM, was able to create a reasonably robust system (it's still working, they tell me). The IT people knew they couldn't replicate it without spending something like a factor of 10 in another system. THIS is why Filemaker is important. THIS is what Filemaker needs to keep in mind. It's a database that real people can use. So if it's a stand-alone system, or a web-ready solution, or a front-end to an SQL database, it still needs to be accessible to real people, not people who've gone to Microsoft school or whatever and sit in the IT department instead of with the people doing the work out there. I think (don't jump all over me) that a lot of us started out by trying to do some simple or not-so-simple tasks for small or medium-sized groups/companies. Most of us, I believe, were like me: reasonably intelligent laypeople who weren't database programmers; we were people trying to accomplish specific tasks to help people get work done. Filemaker was just this little program that we opened up and said, "hmm, maybe this will work." And then we discovered that it wasn't so hard to get it to do what we wanted. It was very Apple Computer, if you want to put it in those terms. Fairly intuitive, pleasant, friendly. Now, how does FM move forward? First, although the complexity of what's available has gotten rather amazing, the first thing is to make sure that somebody sitting down with FM for the first time can still do what we were doing back then. I think this is still true. Most of the more complicated things we (the "developers") want are things that you wouldn't want to do as a newbie. The wonderful thing is that these more complicated things can be there IF you want to use them. They aren't required; they're available, but they're not in the way. David, you're right to defend the project you were involved in. I have no doubt there are some great changes (the new status fields and getfield calc can certainly help cut down on those multiple scripts to do the same thing), but Steve is also right. There are just some really basic things that both "developers" and newbies would find extremely helpful, many of which I believe would not be difficult to implement. There are also some more complicated things that newbies couldn't care less about but which would add serious value to the package for those trying to do more complex tasks. I have a fairly long list of wants, some of which have been addressed in the new release, from what I can tell. (Yes, they are "my" wants.) I would love to share them with others, and have people tell me where I'm full of crap and where I'm spot-on. I'd love to have a sit-down with the FM squad (a lot of us would, probably) to explain why these would be good things, at least to me. If anybody wants to take a look at my list, just let me know and I'll email it to you. This has been a long. rather unstructured message, but I hope it makes some sense. I still swear by Filemaker, but I'm not really keen to spend a bunch of money on an upgrade that hasn't addressed some of the "real people" issues that have been lingering for years. I probably will upgrade, just because somebody else will pay for it. It would be lovely if the FM Squad would fix/improve some of the glaring design drawbacks and give those improvements away as 5.6. Charlie
  11. This may work for you. It is not completely "elegant" as the cursor flashes while it waits, but it's kind of nifty otherwise. Create a global field (in this case "Global Pointer") and put it on top of your calculated Status(CurrentRecordNumber) field, which I have called "This Record". Give "This Record" the "do not allow entry" option. Now make the global field a button and give it the following script: Set Field ["Global Pointer", "This Record"] Go to Field [select/Perform, "Global Pointer"] Loop Exit Loop If [(Global Pointer !=This Record) or (Status(CurrentFieldName) != "Global Pointer")] Pause/Resume Script ["0:00:01"] End Loop Go to Record/Request/Page ["Global Pointer"] Set Field ["Global Pointer", """"] Go to Field [] When you enter the global field, the script enters a loop and waits for you either to change the value or to leave the field, upon which it goes to the record specified by the new value and ends. I use this technique from time to time to allow "quick access" to records in a lot of situations. It doesn't require you to "enter" or "return" to activate the result. (Others may not like that.) If you bail on the field, the script also quits. Hope this helps. Charlie PS: It appears that when I post this message "does not equal" turns into !=.
  12. This may work for you. It is not completely "elegant" as the cursor flashes while it waits, but it's kind of nifty otherwise. Create a global field (in this case "Global Pointer") and put it on top of your calculated Status(CurrentRecordNumber) field, which I have called "This Record". Give "This Record" the "do not allow entry" option. Now make the global field a button and give it the following script: Set Field ["Global Pointer", "This Record"] Go to Field [select/Perform, "Global Pointer"] Loop Exit Loop If [(Global Pointer !=This Record) or (Status(CurrentFieldName) != "Global Pointer")] Pause/Resume Script ["0:00:01"] End Loop Go to Record/Request/Page ["Global Pointer"] Set Field ["Global Pointer", """"] Go to Field [] When you enter the global field, the script enters a loop and waits for you either to change the value or to leave the field, upon which it goes to the record specified by the new value and ends. I use this technique from time to time to allow "quick access" to records in a lot of situations. It doesn't require you to "enter" or "return" to activate the result. (Others may not like that.) If you bail on the field, the script also quits. Hope this helps. Charlie
  13. First, you can't really send "everything" to the front. You need to think of the element on your layout as being like cards in a deck. If they are overlapping, the elements are layered top to bottom. You'll need to arrange them in the proper order to get them to appear the way you would like. Hope this helps. Charlie
  14. Kurt and Vaughan - Many thanks for your help. I've fixed the problem using the scroll-down-the-page method. I've worked with FM for, well, a long time, and I don't think I ever noticed that switching layouts in layout mode keeps the scroll bar in the same place. Learn something new everyday. Thanks to you both. And yes, I've copied the file and backed it up, as Vaughan recommended. Charlie
  15. Greetings. Does anybody know of anyway out of this problem: When I go to two layouts in my solution, the app crashes. (To make it more fun, when I try to restart the app, it gives me the message that I have exceeded the number of users. I have to restart.) I have gone to the layouts with 0 records and it doesn't crash, but as soon as I go into layout mode on the layouts, it crashes. Basically, I just want to kill those two layouts and rebuild them, but I can't get in there to delete the layouts. Any ideas? I really don't want to rebuild the entire file, so any suggestions would be welcome. Thanks. Charlie
×
×
  • Create New...

Important Information

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