David This slightly changes the topic of the OLD on Object fields to a more detailed discussion of the ‘shortcomings' of objects….
(On the topic of the former in my case if I am creating an object in code its likely to be created with the same key order each time so if the ’stringified' version old is not =current then its changed-and even if it was not in the same order it has changed so it is modified). Dealing with the Form Meta data..I would really like it if 4D implemented the object and form meta data concept because you could extract easily the entire representation of a form which is what I currently do with some really interesting code-and i know a number of others have done similar-maybe those of us who are interested in such could pool our code and end up with a common concept of the structure of the Meta object (Object keys named in a common way, common thinking of how to represent form elements etc)-waiting for 4D could be a while-probably there is stuff other people are doing that is better than mine. I will throw some stuff here..if you or others want to work this up feel free to come back to me: There are a couple of Form Propeties and Object properties you cant(I think) get. This was a note i made in my code //the following form settings cannot be obtained in code(V14) //Markers //access //menu bar //print settings //appearance //form type //inherited form table //inherited form name //save geometry and there is an interesting problem that occurs if you have an inherited form(took me a while to work out what the hell was going on)…if an inherited form has an object named ‘variable1’ and the form itself also has ‘variable1’ When you parse the form you get the objects of the form and the objects of the inherited form. When you get the variable associated with ‘variable1’ you might get the one from the form or the one from the inherited form..and it seems random which order you get the objects in-i had to make sure my object names on inherited forms where unique. For your delectation I have put a copy of my version of a form export (this is for a very basic auto made 4D form-i have some really complex forms-and the code building this may not be perfect) on my dropbox- https://www.dropbox.com/s/sr3xfqrxfqton1p/FORM_PO_Purchase_Order_Item_Input.txt?dl=0 <https://www.dropbox.com/s/sr3xfqrxfqton1p/FORM_PO_Purchase_Order_Item_Input.txt?dl=0> (Its easier as a human to read this if you replace the , with cr) I build an object with the data put the object in a blob and create a document for safe keeping. In Previous attempts at this I used XML and boy did that get ugly! I have code that reads this format back in and is able to compare the current version of a form with a saved version of the form-I do not have fancy code that reads this and creates or fixes a form or anything, it just tells me what has physically changed. I would propose: 1) A common way for creating a form(and its objects) in an object. 2) A common way for comparing two complex objects where the ‘structure’ of the objects is known producing a either a human readable(string) of changes or an object representing the changes. e.g a way of comparing two representations of a form. Let know if you or others are interested. Nigel Greenlee > On 23 Feb 2017, at 00:12, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > >> Seems really inefficient, but it work > > 4D has taken pains to say that object fields *are not JSON*. They can be > represented as JSON, but they aren't stored or accessed as JSON internally. > So, it does seem like a good bug report/feature request to make Old work > correctly on object fields. In fact, it's probably one of the more > important field types that it could work on it. Having to serialize it and > run an expensive comparison ourselves feels a bit over the top. > > If you put in a feature request/bug report, shoot a note over here so that > any of us that care can go and vote for your idea. > > Speaking of objects and feature requests, Cannon "Object Module" Smith made > a fantastic feature request the other day: > > http://forums.4d.fr/Post/EN/19051683/1/19051684 > > The idea is to have an automatic, internal C_OBJECT-type structure (a > dictionary) maintained by 4D for each widget on a form. If they did this, > you wouldn't see anything different on the form, but if you wanted to > associated custom attributes or data with the widget (rules, bindings, > hints, extra lookup data, filters, formats, privileges, etc.), you would > know right where to get/set the data. It may sound like a small thing, but > it would be a *huge* win. Just massive. You can do something on this order > now with a custom C_OBJECT in a form or process, but the init/cleanup cycle > is kind of 'heavy'. Also, that makes the price of admission high enough > that most people won't do it. Many will never even have the chance to > understand why this is such a great, great idea. If the feature were built > in, people would fall into it and quickly feel like it was always there. > > I find myself promoting Cannon's idea becuase it's just so darn good that > if I don't, I'll quickly forget where I heard it and then later "invent" it > myself ;-) I used to work with a guy and I'd come in some mornings and say: > "I've had this amazing idea! You're going to LOVE it!" Blank stare. Answer > "Yeah, I loved it yesterday when I told it to you." Cryptomnesia. It's a > thing. Anyway, please go consider and vote for Cannon's idea. Between me > and Peter Hay I think we've gotten the vote count into the low hundreds ;-) > (Peter and I are adding +100 on this feature request.) > > http://forums.4d.fr/Post/EN/19051683/1/19051684 > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
