LaRetta Posted October 22, 2005 Posted October 22, 2005 (edited) I have heavily commented my fields in a Developer/Pro 7.0v1 solution. I now want to access these comments as well as the field, table and file names. I would like it related as data to a Developer vs. 6 file where I keep my own working notes. This sounds nuts ... please bare with me ... I want to view a layout of the file/table as record with the fields as portal records (displaying field name, comment and maybe other stuff like working ideas on enhancements or better calculation concepts to consider - these are my working notes). As I am designing, I want to access this Developer data file (and even make changes to it or add notes) by opening a window. Currently it works great - I can be in Define Fields (in 7) or even ScriptMaker and open a vs. 6 file (my notes) over the top as a small window and easily view both simultaneously. I want to incorporate the real field names/comments etc into my vs. 6 Developer file (I have different file for each business solution I've done). We will be moving to vs. 8 within a month and it would be most helpful right now. Before I attempt to reinvent the wheel, is it possible? I can't make vs. 7 pop up over the top of vs. 7 Field Definitions either, can I (at least I haven't been able to so far)? Update: I should mention that I'm happy to export/import the data to get it into vs. 6. LaRetta Edited October 23, 2005 by Guest
Wim Decorte Posted October 23, 2005 Posted October 23, 2005 When the scriptmaker or Define Database window is open you can't interact with the FM windows behind it. So you could still use a FM6 file, or a FM7/8 runtime.
LaRetta Posted October 23, 2005 Author Posted October 23, 2005 Hi Wim, Yes, I've been using vs. 6 to keep my notes because I can view both simultaneously (even while in 7's Field Definitions or ScriptMaker). Runtime 7? Wonderful! I had moved my Development notes to 7 only to find I lost the ability to view/interact in popup window while working (FM will not do it that I can tell). I realize we have DDR but I find it difficult. I want to use a FileMaker db because I can make it look and act however I wish - I like to search for field names in my Development vs. 6, copy calcs into it for future review etc. while I'm working. What I want is to fill my vs. 6 Development file (now I'll try runtime 7) with the field names and comments as relational (within 7 runtime or 6). I created the comments because I read a year ago that they can be accessed via calculation and my plan was to eventually grab them. But how do I now export it? I suppose I could make a calculation of EVERY field? Yikes! I think I want a value list of the table name, field name and comment - one full field specification per line. I can parse it after the import into Development file. I've been considering the Design functions. I just can't see how to easily export it - or whether I can somehow parse a DDR instead. Fenton presented a demo awhile back on creating a DDR then converting it again (for another problem I had) but I'm currently too brain-tired to *get* it. I just thought someone else had done it and could save me trial/error tiime - I'm on tight deadlines. The ability to open my Development file and view another table's field names and comments (God, I'd love to grab the definitions, field types, etc also but I'm not greedy) is very nice when I'm in Define Fields in vs. 7 and want to view a different table's definitions while I work. I can view them in 6. And copy/paste works from 6 text fields in the calc boxes just fine also. I hear vs. 8 DDR is better but I want to use a database (and my Development db is quite functional) and DDR doesn't allow me to add notes, copy/paste etc. I also could really use this information BEFORE moving to 8 anyway. But how to get the definitions out of 7? LaRetta
Kent Searight Posted October 24, 2005 Posted October 24, 2005 Hi LaRetta, Here's a script I wrote to handle getting my field comments into something usable for me. It sounds to me like you'd want to parse the text from the report field. Doing that was somewhere on my "To do" list. A couple of notes to make sense of the script: I create a layout named "Fields" in my Interface file and I put every field I want to appear in the report on that layout. I always comment in the same manner every time, like so: Field Name in Plain English >> This is where I actually plug my comment. This is mainly so that when I get around to writing the script to parse the report field, I'll have a reference point (>>) for separating "field name in plain english" and the comment. Make sense? Anyway, hope this helps! Go to Layout [ “Fields” (Table) ] Set Field [ Pref_Globals::zc_fieldList_g; FieldNames ( Get ( FileName ) ; "Fields" ) ] Set Field [ Pref_Globals::zv_tempNumber_g; PatternCount ( Pref_Globals::zc_fieldList_g ; "¶" ) + 1 ] Set Field [ Pref_Globals::zv_counter_g; PatternCount ( Pref_Globals::zc_fieldList_g ; "¶" ) ] Set Field [ Pref_Globals::zc_fieldReport_g; Substitute ( LeftValues ( Pref_Globals::zc_fieldList_g ; Pref_Globals::zv_tempNumber_g - Pref_Globals::zv_counter_g ); "¶" ; "" ) & " - " & Substitute ( FieldComment ( Get ( FileName ) ; Substitute ( LeftValues ( Pref_Globals::zc_fieldList_g ; Pref_Globals::zv_tempNumber_g - Pref_Globals::zv_counter_g ); "¶" ; "" ) ); ">>" ; " - " ) ] Loop Set Field [ Pref_Globals::zv_counter_g; Pref_Globals::zv_counter_g - 1 ] Insert Calculated Result [ Pref_Globals::zc_fieldReport_g; ¶ & ¶ & Substitute ( MiddleValues ( Pref_Globals::zc_fieldList_g ; Pref_Globals::zv_tempNumber_g - Pref_Globals::zv_counter_g ; 1); "¶" ; "" ) & " - " & Substitute ( FieldComment ( Get ( FileName ) ; Substitute ( MiddleValues ( Pref_Globals::zc_fieldList_g ; Pref_Globals::zv_tempNumber_g - Pref_Globals::zv_counter_g ; 1); "¶" ; "" ) ); ">>" ; " - " ) ] Exit Loop If [ Pref_Globals::zv_counter_g < 1 ] End Loop
Wim Decorte Posted October 24, 2005 Posted October 24, 2005 I realize we have DDR but I find it difficult. I want to use a FileMaker db because I can make it look and act however I wish - I like to search for field names in my Development vs. 6, copy calcs into it for future review etc. while I'm working. Yes, the HTML DDR is good but not as nice as the old FM6 DDR that gave you everything in a FM db. You can use the XML DDR and write a little XSLT to extract all field comments from the XML DDR and make a CSV file to import into FM. (If you haven't done much XSLT work, it's a good first project). I wrote a little utility in C# (so Windows only) that puts all the field info from the XML DDR into a FM database. I can send it to you if you want to try it out. Not polished, not pretty but it works and it is fast. It can process a 30-file solution in about 2 minutes. and 90% of that time is spent importing into FM.
LaRetta Posted October 24, 2005 Author Posted October 24, 2005 Thank you both so much!! In truth, I figured I must have sounded like a nut-case (more than usual) making such a request. It's been on my TTD since 7 came out. I wanted to use vs. 7 for Development so I could (possibly) use Evaluate() also. Your script is quite interesting, Kent. My original thought was to create a layout for every table and have script flip through the layouts (to get the table name). Your example would still require a different layout for each table (if not related), right? It might be simpler to create a hub of TOs (cartesian-joined) just for this purpose (allowing all fields to be on one layout). I have no distinction between field name and comment. And adding the field name would take a bit of work (50 tables and probably 300 fields) so I might work around that part. This is a great idea and I shall certainly devour it. FM6 had FM db for DDR, Wim? I didn't use DDR then. Yes, I would be most grateful for the file. Because, in truth, if I'm going to bother grabbing information, I want to grab it all. Yes, I AM greedy. And learning to parse DDL would teach me so much and I can learn to pull anything from it (hopefully). I may end up using a combination of both methods but you can bet both will be pulled into my tool kit. Update: Oh, Kent, I see you mentioned you had an interface file so they probably are already all related! I don't have separation. LaRetta
Kent Searight Posted October 24, 2005 Posted October 24, 2005 My original thought was to create a layout for every table and have script flip through the layouts (to get the table name). Your example would still require a different layout for each table (if not related), right? It might be simpler to create a hub of TOs (cartesian-joined) just for this purpose (allowing all fields to be on one layout). Update: Oh, Kent, I see you mentioned you had an interface file so they probably are already all related! I don't have separation. LaRetta You can even put fields from unrelated tables on your layout and it will return comments from those as well (as long as they appear in the relationships graph). Try the attached example and take note that I'm reporting from TableB (it has no fields, no relationships) You and Wim have certainly given me food for thought about improving upon my field reporting. The way I do it now is I run the script and then print out the results (so I can see them when the script dialog window is open, for instance). But I like the idea of a runtime solution I can refer to "live" onscreen, kind of like Analyzer except with control over the sort order. FYI The sort order in my example is defined by the chronological order in which the fields were placed on the layout. This is why my "To do" list includes parsing the fields out and possibly creating a record for each field and its comment. Then I'd have much better control over sorting. FieldReporting.zip
LaRetta Posted October 24, 2005 Author Posted October 24, 2005 Hi Kent, Thanks for the file. It is very clear and would be easy to implement! Yeah. Nothing beats having an FM file sitting in a small window on top of Script Maker or Field Definitions with all the functionality we need. My runtime will contain my client solutions (1:n client, files, tables and fields). I've found myself referring back to prior designs and calculations (maybe you'all never do that but I like the ability now). It's fine for other types of software to produce what we need but the reason we design is simply because no other software gives us EXACTLY what we want to our specification. We're a persnickity bunch ... that's why we're into database management, after all. LaRetta :wink2:
Recommended Posts
This topic is 7027 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now