List Box Basics

Greetings All! So I guess this is another one of those “Don’t reinvent the wheel if I don’t have to” queries. If any one would be so kind as to point me in the direction of useful resources pertinent to the programmatic management of the data source in selection-based List Boxes,

Re: pointers to arrays

OK If I read that correctly, that will create the arrays for pass 1 through the loop, but what about creating the arrays for pass 2, and any subsequent passes. I expected to create the arrays, as they were needed, for each pass. something like For ($i;1;Size of array(EDLBlockArray)) If ($i<10)

Re: pointers to arrays (and List Box Basics)

A past discussion mentioned creating arrays on the fly using a Listbox command that creates columns. This is for an array listbox. http://livedoc.4d.com/4D-Language-Reference-16.2/List-Box/LISTBOX-INSERT-COLUMN.301-3433513.en.html C_POINTER($NilPtr) LISTBOX INSERT

Re: [Warning] Settings properties values on object field by object notation

THIS is definitely a bug. Past behavior is if a field is modified (even assigning itself to itself) sets the 'dirty' flag, and the ENTIRE record is to be saved. On Tue, 31 Oct 2017 09:58:09 -1000, John Baughman via 4D_Tech wrote: > > ALL RECORDS([Patient Record]) > [Patient Record]

Re: pointers to arrays

Peter, IF your code will never be compiled the first code I sent will work, and you will be creating arrays 'on the fly', if you do this, I suggest you create local arrays, array names starting with a '$', so that they are thrown away at the end of the process/method. IF you code will EVER be

pointers to arrays

Hi I want to achieve the following: To Loop through a block of code (the number of times will be determined elsewhere, but may well be different each time). Create a set of arrays that will have the same name + the loop counter, for each pass through the loop So pass 1 might create 3 arrays called

Re: pointers to arrays

Thank You And How do I create the Arrays in the First Place -pm On Tue, Oct 31, 2017 at 7:32 PM, npdennis wrote: > > Im pretty sure I need to use pointers to accomplish this, but I dont > know how. > > Try the command Get Pointer… > > $p:=Get Pointer(“Array201”) > or >

Re: pointers to arrays

> And How do I create the Arrays in the First Place If you are running compiled you I think will need to type the arrays in a method someplace so the compiler knows about the arrays. I know that some variable types don’t need compiler declarations, but I think arrays do. // Some method maybe a

Re: pointers to arrays

> Im pretty sure I need to use pointers to accomplish this, but I dont know how. Try the command Get Pointer… $p:=Get Pointer(“Array201”) or $x:=201 $p:=Get Pointer(“Array”+string($x)) However compiled you may need to have the arrays declared some place. Neil

Re: pointers to arrays

some pseudo code to follow: an out line would be: if the code is not compiled the following will work, if it is (or is going to be) then you need to create the arrays before hand. For the example all arrays are text. Array pointer($New_Array_Handles;0) For ($i;1;$Number_Of_Arrays)

Re: pointers to arrays

> but that doesnt work, hence my question If you want to run compiled you will need to use a list box to create dynamic arrays… or declare every possible combination you will use in a method and use get pointer… However in your case you might be able to use a 2D array, or depending on what

Re: pointers to arrays

compiler declaration(s) Array (Variable_Name;Size) is the type of the array you want, text, longint, etc On Tue, 31 Oct 2017 19:42:42 +, Peter Mew via 4D_Tech wrote: > Thank You > And How do I create the Arrays in the First Place > -pm > > On Tue, Oct 31, 2017 at 7:32 PM, npdennis

Re: [Warning] Settings properties values on object field by object notation

> It looks like this bug ACI0097454 was marked as Standard Behavior on October 24th. Smells like a bug. Looks like a bug. Sounds like a bug. Walks like a bug. I mean, if you have a light switch that gives you a shock every time you touch it, you wouldn't say "Oh, it always does that. It's

identify duplicates

I'm looking for a strategy to identify duplicate records in a table - that is, records for which 3 fields are identical across two or more records - or in another case, where a single field is not unique. Does anyone have a suggestion on how to proceed? -- David Witton

Re: identify duplicates

The third parameter of DISTINCT VALUES really saves work. Here is a strategy to find dups in a field within a selection. The set can be a listbox highlight set. // // Method: DuplicatesToSet // - // INPUT1: Pointer - field //

Re: [Warning] Settings properties values on object field by object notation

I’m glad I came in today. > On Oct 31, 2017, at 1:35 PM, Charles Miller via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > It must be a duck, cause calling this standard behavior is quackers. ** 4D Internet Users Group (4D

RE: identify duplicates

Hi David, Would the DISTINCT VALUES command help? http://doc.4d.com/4Dv16R4/4D/16-R4/DISTINCT-VALUES.301-3317277.en.html Best Regards, -Tai B. -Original Message- From: 4D_Tech [mailto:4d_tech-boun...@lists.4d.com] On Behalf Of David Witton via 4D_Tech Sent: Tuesday, October 31, 2017

Re: pointers to arrays

Peter, This is easy to do with local arrays and dynamic variables. It looks like you only need to build text arrays. You can declare a local array, ARRAY TEXT($aText2d;0;0). Then you can resize this to add more 'columns' as needed and populate them. Next you need to populate the listbox. First

RE: identify duplicates

Hi David, Perhaps using GROUP BY like Neil suggested in an SQL call in a similar fashion to the following will help: Begin SQL SELECT tbl.fld_1,tbl.fld_2,tbl.fld_3,Count(*) AS recCount FROM tbl GROUP BY tbl.fld_1,tbl.fld_2,tbl.fld_3 HAVING Count(*)>1 INTO

Re: pointers to arrays

OK thanks There will be a maximum of 16 passes through the loop, with a maximum of 14 arrays declared on each pass. each array could have between 1 and a couple of hundred elements. it depends on the size of the original document, from where all the original data is imported. each one of the 14

Re: [Warning] Settings properties values on object field by object notation

It must be a duck, cause calling this standard behavior is quackers. There are many issues with object fields. I for one refuse to use them (Yes I know how powerful they are and can be) as I do so much with sql and can not get them using a sql statement. I have commented before that 4D should not

Re: identify duplicates

As has been recommended distinct values is your friend but it really depends upon what you mean by duplicates. For example Charles and Karl are the same name but in different languages. So what do you mean by duplicates. Also is case important or do able and Able equal each other Regards

Re: identify duplicates

> I'm looking for a strategy to identify duplicate records in a table - that > is, records for which 3 fields are identical across two or more records - > or in another case, where a single field is not unique. If you are just looking for fields that are exactly the same, the SQL with GroupBy

Re: List Box Basics

Hi Steve, Actually, there are plenty of resource on kb.4d.com about programming in selection based list box context. Here are some of the reference. http://kb.4d.com/assetid=77856 http://kb.4d.com/assetid=77873 http://kb.4d.com/assetid=77871 http://kb.4d.com/assetid=76585

Re: pointers to arrays

Hi Kirk Yes all the arrays are Text Arrays. My aim is to import all the data and load it into the various arrays. The basic problem is that I dont know in advance, how much data there will be. Think of it like this. There maybe beween 1 and lets say 16 audio channels. each audio channel maybe

Re: Method to put a c-obj (or JSON) into a hierarchical list

On Oct 31, 2017, at 2:00 PM, Koen Van Hooreweghe wrote: > I’ve been bitten by this a while ago. There is a difference in behavior > interpreted and compiled. Eg following piece of code: > > 1 C_OBJECT($obj) > 2 C_TEXT($text) > 3 C_LONGINT($long) > 4 > 5 OB SET($obj;"property";"value”) > 6 > 7

Re: [Warning] Settings properties values on object field by object notation

On Oct 31, 2017, at 2:00 PM, Chip Scheide wrote: > OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty. > > And, yes, I too was told that the engineers were leaning to declaring > this as standard behavior. Why? I have not a clue. I can guess the answer to that. The

Re: [Warning] Settings properties values on object field by object notation

Chip, Record 0 is the first record in the table. Of course it may have been deleted and the number not reallocated. Regards, Wayne Sent from my iPhone > On 31 Oct 2017, at 15:03, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Alberto, > doesn't Goto REcord ([table];0) -

Re: [Warning] Settings properties values on object field by object notation

> Le 31 oct. 2017 à 05:03, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Alberto, > doesn't Goto REcord ([table];0) - generate an error? > there is no record number 0 Hi Chip, "physical" record numbers start from zero, see here:

Slow characters visualization

Hi all, I use 4D V15.5 on windows. Sometimes when i write a method the editor is not fast responsive, i fact i can see the character digited only after one second. Someone know th reason, and how i can solve? Thanks Ferdinando

Re: [Warning] Settings properties values on object field by object notation

On Tue, Oct 31, 2017 at 8:21 AM, Alberto Bachler via 4D_Tech < 4d_tech@lists.4d.com> wrote: Just a quick note of thanks for posting this behavior to the list. On Tue, Oct 31, 2017 at 3:49 PM, John Baughman via 4D_Tech < 4d_tech@lists.4d.com> wrote: ...and to you too John for posting that you

Re: Method to put a c-obj (or JSON) into a hierarchical list

Hi Tim, I’ve been bitten by this a while ago. There is a difference in behavior interpreted and compiled. Eg following piece of code: 1 C_OBJECT($obj) 2 C_TEXT($text) 3 C_LONGINT($long) 4 5 OB SET($obj;"property";"value”) 6 7 $text:=OB Get($obj;"nonexistent") 8 $text:=OB

Re: [Warning] Settings properties values on object field by object notation

> > The problem is that the dirty flag is not set when dot notation is > used against an object field. In your scenario the following will work > … field modified = field modified --right?!?! > OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty. > > And, yes, I

Re: [Warning] Settings properties values on object field by object notation

> On Oct 31, 2017, at 3:17 PM, Keisuke Miyako via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > to explicitly indicate that the object has been modified, just use the line > > [myTable]myObjectField:=[myTable]myObjectField > > and you have total control of when to save the field, > which

Re: [Warning] Settings properties values on object field by object notation

>I am going to post here a response I got from Tim Penner in the TAOW a bit earlier today. While it does not change my mind that this issue should be characterized as a bug, it does clarify what the issue really is. It's a bug. If 4D wants to document it as standard behavior, that's their

Re: [Warning] Settings properties values on object field by object notation

Keisuke, I don't think anyone is arguing for a 'Save always' system. I think we are saying IF the data (inside the object field) has been modified - it needs to be saved, if the request is made to save the record, REGARDLESS of how the modification occurred. a direct assignment via dot

Re: [Warning] Settings properties values on object field by object notation

I wasn't trying to avoid taking responsibility, I feel very sorry for that. I thought it was also quite clear in Tim's reply which was reposted here, that we failed you on this, and that we are in the process of updating the documentation. but again, I apologise. > 2017/11/01 10:46、Tim Nevels

Re: [Warning] Settings properties values on object field by object notation

Is a ‘2’ in BOLD type sufficiently large, David? > On Oct 31, 2017, at 5:39 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > On Wed, Nov 1, 2017 at 10:23 AM, Tim Nevels via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > >> I can guess the answer to that. The engineer responsible

Re: [Warning] Settings properties values on object field by object notation

like a global preference, to the effect of "Call OB Copy implicitly when performing object assignments" it is an interesting point of view, to frame it as an issue of the assignment operator being different, as opposed to how objects and their properties are different "because they are

Re: [Warning] Settings properties values on object field by object notation

I am going to post here a response I got from Tim Penner in the TAOW a bit earlier today. While it does not change my mind that this issue should be characterized as a bug, it does clarify what the issue really is. Am I the only one that was clueless that there is a field dirty field flag that

Re: [Warning] Settings properties values on object field by object notation

> OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty. > And, yes, I too was told that the engineers were leaning to declaring > this as standard behavior. Why? I have not a clue. obviously I can't speak for "the engineers", but I would not rush to the conclusion that it is

Re: [Warning] Settings properties values on object field by object notation

On Oct 31, 2017, at 8:17 PM, Keisuke Miyako wrote: > to explicitly indicate that the object has been modified, just use the line > > [myTable]myObjectField:=[myTable]myObjectField > > and you have total control of when to save the field, > which results in better performance, immediately as

Re: [Warning] Settings properties values on object field by object notation

> it is an interesting point of view, > to frame it as an issue of the assignment operator being different, > as opposed to how objects and their properties are different "because they are references". I think that the real issue for a 4D programmer is that a record is a persistent data store and

Re: Method to put a c-obj (or JSON) into a hierarchical list

Er - "I wasn't aware the error handler would get tripped by line 14" is what I meant to type. On Tue, Oct 31, 2017 at 5:09 PM, Kirk Brooks wrote: > I wan't aware that the error handler would get tripped by that though. > -- Kirk Brooks San Francisco, CA

Re: [Warning] Settings properties values on object field by object notation

to me... using either OB SET(object_field;value) = Object_field.property := value They SHOULD do the same thing, either BOTH set the flag to save the data, or neither do. In all other 4D field types " := " says 'I changed this value', make sure the new data is saved if such a request

Re: [Warning] Settings properties values on object field by object notation

Quackers. > On Oct 31, 2017, at 9:17 PM, Keisuke Miyako via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > "standard behaviour" is a specific term that means the result is "expected, > if not intended" by design or specification.

Re: [Warning] Settings properties values on object field by object notation

On Wed, Nov 1, 2017 at 1:05 PM, Keisuke Miyako via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > I thought it was also quite clear in Tim's reply which was reposted here, > that we failed you on this, and that we are in the process of updating the > documentation. > If changing a field and then

Re: [Warning] Settings properties values on object field by object notation

This bug was first discovered in July of 2016. See the NUG thread "Does 4D Support Dotted Notation in Object Fields?” if you are interested in how it was discovered (thanks to Douglas Von Roeder). ACI0095526. Even though I filed the bug report, I can think of at least twice since then that

Re: [Warning] Settings properties values on object field by object notation

On Wed, Nov 1, 2017 at 10:23 AM, Tim Nevels via 4D_Tech < 4d_tech@lists.4d.com> wrote: > I can guess the answer to that. The engineer responsible looked at the > code and said, “yeah I can fix that, but it will be a lot of work”. And > somebody said, "OK then don’t bother. You’ve got more

Re: [Warning] Settings properties values on object field by object notation

I hate to repeat myself, but it seems the problem with object notation is that it's not as straightforward to know if a field has been changed or not. perhaps until now, we have been thinking of simply code like [myTable]myField.prop:="123" and it seems crazy that 4D doesn't understand that the