Re: Defining and documenting Objects

David, Any chance you might make this system available to the rest of us poor and unworthy? as a component? for a fee? Chip On Fri, 12 Oct 2018 15:35:03 +1100, David Adams via 4D_Tech wrote: > > Anyway, with all of that stuff in place, you then can build your own type > declaration and validati

Re: Defining and documenting Objects

I recently went through my code and removed IP vars, to future proof my code for pre-emptive possibilities. I went from >500, including sets, to 1 which is a set. Have not done Process vars, still in v13 so Chip On Thu, 11 Oct 2018 18:09:23 -0600, Jody Bevan via 4D_Tech wrote: > > Our goa

Re: Defining and documenting Objects

Just went back and looked at the thread. And, again, I see that there's huge amount of confusion and murk about what constitutes a "global" variable. Flow of control, type, and scope are all basic language design features. Scope in 4D ispeculiar. Scope is typically tied to a collection of metho

Re: Defining and documenting Objects

Keisuke, Thanks for the quick response, it's always great to hear from you. Yes, I think you've described exactly the situation. I've got a collection which is tied to a listbox. I've got an automatic selected object. I've got an object display bound to the selected object. I change the source va

Re: Defining and documenting Objects

Is this about a cell in a collection listbox? the reason why a redraw needed to be forced (Form.col:=Form.col) was related to how ref. counting works, in particular, when you have an expression defined as the "current item" property. the current item object can be referenced from another object o

Re: Defining and documenting Objects

I don't follow the list any longer, but I do check in to look for answers. Today I was looking for the an answer to "why don't my object variables on fields automatically redraw when changed?" Didn't find it, does anyone have a workaround? While I was checking on my question, I ran into this massiv

Re: Defining and documenting Objects

We rewrote our shell (that has been updated ever few version since 3.0 when I write the first shell). Our goal was to have as few of global, and interprocess variables as possible. We got a long way in before we needed more than a few of each. Yes, one of those is for the hiding/showing of list

Re: Defining and documenting Objects

the collection type listbox introduces a new "meta" property. if each row in the list is an object or an entity, you could have an optional static This.meta property, which would control properties such as style, colour, disabled, selectable, at the row or cell level. http://doc.4d.com/4Dv17/4D/

Re: Defining and documenting Objects

Olivier, First - nifty hack. Second - can you do that with a collection or object based listbox? On Thu, Oct 11, 2018 at 11:15 AM Olivier Flury via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Well, not sure if this is what you need, but you can insert a dynamic > column into a list box, get a pointe

Re: Defining and documenting Objects

Neil, You are correct. I think this is an example of how deep the changes are to accomplish ORDA. But there are a lot of changes in the works on forms (viz dynamic forms) so it will probably change too. On Thu, Oct 11, 2018 at 7:33 AM Dennis, Neil via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > I

RE: Defining and documenting Objects

Dennis, Neil: >> I LOVE it that there are no longer ANY global variables necessary when >> working with forms > > Is there a way to do hidden rows in a list box? So far I have not found a way > and still have to use a process array. If you know of something please share. Sorry, maybe my enthu

Re: Defining and documenting Objects

Peter Jakobsson so eloquently writes: >The original selling point of 4D was that it was stateful and that >statefullness >is what gave us massive productivity gains. Lower level languages like the >Microsoft developer platforms, Delphi and even Javascript/Python type >environments had the versati

Re: Defining and documenting Objects

Koen Van Hooreweghe writes: >Objects can be 'exported' to JSON quite easily: $json_text:=JSON >Stringify($4Dobject) Then you can expose this text data to the external system. >The other way around is: $4Dobject:=JSON Parse($json_text) >I really advise the step up to v15 and further. Objects are

Re: Defining and documenting Objects

On Oct 11, 2018, at 9:37 AM, Peter Jakobsson wrote: > I think I might happily pay the price of recreating the variable table for > every process (since I never noticed any adverse effect of that) and use > naming conventions to avoid conflicts to get those features ! ;) > > The original selling

RE: Defining and documenting Objects

> I LOVE it that there are no longer ANY global variables necessary when > working with forms Is there a way to do hidden rows in a list box? So far I have not found a way and still have to use a process array. If you know of something please share. Neil -- Privacy Disclaimer: This messag

Re: Defining and documenting Objects

I have no menus in my current work, menus for a form are built dynamically "On Activate", disposed of "On Disactivate". The menu ref is kept in a form variable, and is used on contextual click to pop-up the current menu. Don't hesitate to ask if there are any questions. -- Jim Dorrance jim.dorra..

Re: Defining and documenting Objects

Bernd, On Wed, Oct 10, 2018 at 11:49 PM Bernd Fröhlich via 4D_Tech < 4d_tech@lists.4d.com> wrote: > there are no globals required for menus (I assume here that you are > talking about popup menus in the form). > So true. This deserves its own thread. In fact unless you have some extended lookups

Re: Defining and documenting Objects

> On 11 Oct 2018, at 12:02, Bernd Fröhlich via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > All true, but with globals you can have hard to find side effects. > E.g. i have a lot of buttons and other variables on a lot of forms use > "standard" global variables (bOK, bCancel, bSave, bPrint, bWh

Re: Defining and documenting Objects

Peter Jakobsson: > Out of interest, what advantages does this give you over using a global ? The > advantage of a global to me is that it preserves state throughout the life of > the form without any coding. (For example you don’t need to keep using Object > get Pointer(“myPopUp”) all over the

Re: Defining and documenting Objects

Hi Tom, Objects can be 'exported' to JSON quite easily: $json_text:=JSON Stringify($4Dobject) Then you can expose this text data to the external system. The other way around is: $4Dobject:=JSON Parse($json_text) I really advise the step up to v15 and further. Objects are quite fun to work with

Re: Defining and documenting Objects

> On 11 Oct 2018, at 08:49, Bernd Fröhlich via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > there are no globals required for menus (I assume here that you are talking > about popup menus in the form). > Just give them an objectname, get a pointer in the "on load" phase with > Object Get Point

Re: Defining and documenting Objects

Peter Jakobsson: > So what I’m doing now is just using a single object to hold all form > properties that I’d previously used globals for. Then just use globals where > required for active objects like menus. Hi Peter, there are no globals required for menus (I assume here that you are talking

Re: Defining and documenting Objects

> On 5 Oct 2018, at 09:15, Paul Dennis via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > With tables and records and the structure it's relatively > straightforward to track through the code and work out what's going > on. I can see this being a real problem with object

Re: Defining and documenting Objects

Hi This is a good point made by Paul... > On 5 Oct 2018, at 09:15, Paul Dennis via 4D_Tech <4d_tech@lists.4d.com> wrote: > > With tables and records and the structure it's relatively > straightforward to track through the code and work out what's going on. I > can see this being a real problem w

Re: Defining and documenting Objects

Kirk, Good point, well made. Paul -- Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/option

Re: Defining and documenting Objects

Paul, You know it's perfectly acceptable to just not even worry about it. Personally I never wrote a SOAP API or client and it looks like I never will. :-) If you don't need dot notation and don't see anything on the horizon that will require it spend that time doing other things. I've seen some i

Re: Defining and documenting Objects

I've been thinking about it more from the point of practicalities than the coding. I understand how we can create documentation of the objects. My problem is three years down the line when you revisit some old code written by third-party. With tables and records and the structure it's relatively st

Re: Defining and documenting Objects

If anyone is a little intimidated about writing JSON validation schema from scratch (I am) there are some online resources to assist. One that's particularly easy to use is https://www.jsonschema.net/ On this site you can paste in a properly formatted JSON and the site will infer the schema. The

Re: Defining and documenting Objects

as a general rule, if objects are meant to share a common structure, the choice should be to use a record, not a single object field. the closest thing we have to a "class" in 4D is a table, not an object. http://doc.4d.com/4Dv17/4D/17/Dataclasses.300-3777698.en.html 2018/10/04 23:24、Chip Scheide

Re: Defining and documenting Objects

the recommended way to so this in 4D is to use JSON Validate. http://doc.4d.com/4Dv17/4D/17/JSON-Validate.301-3730393.en.html the structure of an object can be defined using a JSON schema, a blueprint of a class of object, itself written in JSON. kind of like what XSD or DTD are to XML. https://

Re: Defining and documenting Objects

I do not use objects - not up to a version of 4D that supports them, yet. My thought on handling documentation of an object's contents... this is probably worth what you are paying for it... :) 1 - In every system, or component install a comment only method outlining your conventions. This con

Re: Defining and documenting Objects

Thanks Kirk, I was afraid you were going to say that. Ive got multiple developers on our app all with different habits plus me and I am the worst. I have to give this some thought. -- Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html ***

Re: Defining and documenting Objects

Aparajita: "You *are* moving memory if you extract the array from an object. Not a huge amount, but not nothing." Thank you for confirming how that works in ObjectTools. "I’m not sure what the motivation was for implementing those commands yourself, but whatever." The motivation was that the OBJ_

Re: Defining and documenting Objects

> BTW, I mimicked the OT GetArrayLong/Text/Date* commands and the Find in > array command from Object Tools in my copy of OBJ_Module. The approach that > I took was to extract the array from the object and do a find in array and > I was thinking that, perhaps, that would incur a penalty. I don't ha

Re: Defining and documenting Objects

Kirk: I did some timing tests on dotted notation with C_Object, the OBJ_ module, and my routines that use wrappered Object Tools commands. "Ain't nuthin' slow at 4.2 Ghz" Even running interpreted code, there was no perceptible difference in performance of a few hundred or thousand iterations. Wh

Re: Defining and documenting Objects

Jim, In v15 I frequently use something like: OB SET($obj;\ k some key; "the value";\ k another key; "another value") And so on. This also worked with Canon's OBJ module: OBJ_SET_TEXT($obj;k some dot notation key;"text to set") where: k some dot notation key = "a.b.c" In v17 to do that usin

Re: Defining and documenting Objects

Why are constants less useful? If the value is equal to the constant, it avoids potential upper/lower case problems, no? On Wed, Oct 3, 2018 at 5:41 PM Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> wrote: > Paul, > You touch on an excellent point about using objects. At the heart of it is > your

Re: Defining and documenting Objects

Paul, You touch on an excellent point about using objects. At the heart of it is your naming convention. We haven't had to worry about naming too much in the past. Variable names aren't case sensitive and you could always use the COMPILER_ methods to document the IP and process variables. And the s