Re: Benchmark Speed Test Method

[steve simpson via 4D_Tech]

On Fri, Apr 5, 2019 at 3:00 PM  Neal Schaefer wrote:

> [snip]
>
> * We're getting a new Windows 2016 server for our 4DServer, and before I
> migrate, I'd like to write a benchmark speed test to run before and after.
> I'd like to measure create, edit, delete records, processing, IO, file
> copying, and other relevant functions. We're also migrating from v16.6 to
> v17 later in the year, and I'd like to run it again before and after the
> upgrade. I'm wondering if anyone has a method they've written for this
> purpose that they might be willing to share?*
>
We'd be very interested in that too. And Neal, I hope you share your
results when finished.

Also, has anyone moved up to v17 web server yet application? (Not "web
area", but rather the full "web server application") Can you tell how it
compares to v15 please? Any issues one should be aware of?
-
Stephen Simpson
Cimarron Software
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

​RE: Server Monitoring...

[steve simpson via 4D_Tech]

https://uptimerobot.com/

Pretty robust; all kinds of triggers (IP, port, url, keyword, etc); easy to
configure. Up to 50 sites free. Bulletproof last few years for several
dozen projects.
-
Stephen Simpson
Cimarron Software
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

v17 ready for prime time?

[steve simpson via 4D_Tech]

I see that a lot of you are using v17, doing active development with it,
testing it out with current projects, etc. I don't normally move production
projects into a new version until the xx.2 or xx.3 iterations, but am
wondering if some of you who are actually using v17 in production could
chime in with your opinion as to whether it is safe to move straight from
v15.5 to v17 now, or best to move first to v16 and wait for a couple more
updates to v17. Is it ready?

-
Stephen Simpson
​Cimarron Software​
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

​Re: What do you use to monitor your offsite servers?

[steve simpson via 4D_Tech]

On Mon, Jul 16, 2018 at 2:01 PM,
​
John Baughma wrote:

> I really like Microsoft Remote Desktop for Mac which can be downloaded for
> free from Microsoft. They regularly update it. Clipboards are shared and
> you can designate one or more folders on your Mac as network drives which
> automatically mount when you log in.
> ​[snip]​
>
>
​+1
--
Stephen Simpson
Cimarron Software​
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Save Record($vptr_Table->)

[steve simpson via 4D_Tech]

On Sun, Jun 10, 2018 at 5:01 PM,
​
​
Jody Bevan  wrote:

The method that this err occurs in is used hundreds of time throughout the
> system. All record saves go through it.
> ​[snip]
>

​Jody, do you happen to have a "mandatory" field in this table that
normally gets filled in but in this one instance is not being populated?

-
Steve Simpson
Cimarron Software​
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: ​Document capture

[steve simpson via 4D_Tech]

​
K
​​
enneth, sounds to me like you are on the right path. Much of it depends on
the sheer volume of documents. As some pointed out, a vast number of
documents in a single folder can bog down OS storage systems, although that
is way less a problem now than it was several years ago. Much also depends
on why you are storing them and what you have to do with them later. It
might come in handy to store the doc type, in case you need to call a
specific routine (or sub-launch a special app or whatever) in order to view
it directly. Also, I've found over the years that one can easily create all
kinds of workable routines for the computer (4D) to store and retrieve
documents, but invariably one will find that there is a need for a human to
go through those folders trying to find a specific document, so I try now
to make my storage folder mechanism and file naming conventions somewhat
human understandable, or at least logically understandable within the scope
of the application's world in case something comes up and a human has to
dig through that repository. Another important consideration is how
redundant or robust your storage needs to be. Depending on volume, I'm a
huge fan of storing raw source documents in AWS S3 buckets. One of our
projects is digitizing, indexing, and providing access to county courthouse
documents in both tiff and pdf format. Millions and millions and millions
and many many terabytes of documents that are indexed to 4D fields so users
can search/sort/report normal 4D digital records and/or then download the
actual digital disk document(s). We quickly ran out of disk space in normal
office and enterprise hard drive environments, especially with duplicate
backups in geo diverse locations since we can't afford to lose that many
documents. AWS cloud storage was the answer for us (but similar to most of
the large cloud storage systems). There are lots of ways to access cloud
buckets, depending on who you go with, but we chose a "Cloudberry Drive"
solution (cloudberrylab.com) so that AWS buckets become available locally
as familiar network mounted drives (and they work with all the large cloud
vendors); document access and manipulation works as if you are in a local
lan type world - but with unlimited storage capacity. Surprisingly fast and
efficient and cost effective. As for our document naming and placing
routines, we obviously start the folder hierarchy with the "county name".
Over time we've worked out a storage system that is well suited to this
courthouse world based on the year, the month, and the day of the filing
date for each document, combined with the county clerk's "instrument
number" or in some counties the vol/page nomenclature they use. Fairly
universal stuff in the court system vertical market, but probably not so
meaningful in yours. Nonetheless, the naming and folder hierarchy logic is
an important element to get right at the beginning.

Steve Simpson
​Cimarron Software

On Thu, Jan 25, 2018 at 1:24 PM,
​​
​K​
​
​
enneth Geiger  wrote:

>
> ​[snip]
>
> I’ve not started prototyping anything yet but I think I’ve got a viable
> approach. The server will have a shared directory with a sub-directory for
> each of their clients. There will be a dialog where the user enters
> information about the document, including a text box where they can enter a
> brief description of the document. The user would then drag-and-drop a scan
> of the document onto the description text box and an “on drop” event would
> trigger a document capture method. This method will have to rename the
> document (the file-name will be created automatically within 4D without
> changing the extension), check that the relevant sub-directory exists on
> the server (and create it if it does not), and then save the renamed file
> to the server.
>
> If any of you have done something similar, I would really appreciate any
> feedback on my approach and would welcome any suggestions, pseudo-code, or
> code that you would be willing to share.
> ​[snip]
>
**
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
**

Re: ​NB: Pre-emptive mode hassle

[steve simpson via 4D_Tech]

On Wed, Oct 11, 2017 at 3:00 PM,
​
Tim Nevels wrote:

> ​[snip]
>
>
> I sure can. Remember when C_OBJECT variables were introduced? There were
> several developers here that talked about completely overhauling all their
> code to eliminate process and interprocess variables and replace all of it
> with object variables. Code was working fine. They just wanted to use this
> cool new variable type.
> ​[snip]
>
> I do a lot of UI work with 4D. I love doing UI work. Windows and dialog
> boxes that users deal with all day every day. So 4D is great for a lot of
> the work that I do.
> ​[snip]​
>

​+1
_
Steve Simpson
Cimarron Software
**
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
**

​Re: UUID vs Longint primary key

[steve simpson via 4D_Tech]

On Tue, Aug 8, 2017 at 11:00 AM,
​
Chip Scheide <4d_o...@pghrepository.org> wrote:

>
> Worse, I've found that the same product, from the same vendor in
> differing purchase amounts (1 vs case) is the same part number, but
> different pricing! So.. even a check on part numbers is insufficient to
> stop duplicate entries.
>
> ​Well I believe there are "dupes" and then there are dupes. There are
unacceptable dupes and there are dupes you have to or need to live with.
And then there are "near dupes". Like your example above. That is not
"really" a dupe because there is one field/col, pack size, that is NOT
duplicated (case vs 1). On and on.

This all started with David making a broad blanket statement about "data
integrity" and "row duplication" and how using "synthetic" record ID keys
ruined the ability to automatically​

​filter out "dupes". (I _think_ that was your point David. Please correct
me if not.) And in that strict sense, if a "row" is really actually
absolutely duplicated, that is _probably_ bad. Or maybe not if you didn't
include that "pack size" field that would have changed the row to unique.
Or all the other examples cited on this thread about duplicate names that
were not _really_ duplications; they just needed a little more information
included in the "row" to better define it. In fact we all used to
experience it right here nearly daily with our Walt Nelson(Guam) vs Walt
Nelson(Seattle) signatures. Constantly confusing without that one little
added tidbit.

So my point was, ​it all depends. And sometimes you have to design your own
system differently or provide tools within your current system to suss out
what, how, why and when a "dupe" occurred. And how to - or IF to - fix it
or prevent it or even find it.

I too am definitely a convert to using
 UUID over longint
​. AND in using them in preference to some construction using row data
itself which may well change as the business grows/changes and will NOT
play well when you absorb new data sources (buy a competitor for example
with nearly identical inventory items or combine existing standalone data
installations into one big common enterprise bucket, or decide for all
kinds of business reasons to extract a certain batch and combine it with
another batch in a different bucket, etc.etc.etc. Data duplication of one
sort or another are bound to occur in many of these "growth" scenarios and
more often than not the merging and cleaning of those dupes is not
reducible to some sort of algorithm without human hands to help. Or
whatever.

As ​
Neil succinctly describe
​d
:

 - UUID is faster (do to "random" data in the index)
>  - UUID solves problems with distributed systems that sync
>  - UUID fixes the home grown sequence problem with transactions
>  - UUID is not easily readable by human and keeps me from being tempted to
> expose them :)
>
> ​And to Chip's point, I DO sometimes expose those UUIDs as read only info
on certain Admin Review pages. I sometimes place a button to "copy to
pasteboard" if it is appropriate that the admin might desire to do some
searching with that UUID - for as we all know​, they are hellishly
difficult to type. And in many projects I retain that seq longint idea
because it really IS a useful human marker that is easier than a date:time
stamp to read and quickly sort on and in general "glom" as you scan down
long lists of rows. But I've been burned way too many times to ever use it
again as a unique recordID. I now consider it a user interface type aid
only, still useful as a ProductID or some such in many cases. But not as a
Unique-Unvarying-Forever-Regardless-Of-Source-Or-Destination-Record-Key.

Steve Simpson
**
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
**

​Re: Preventing Duplicate Data WAS UUID vs Longint primary key

[steve simpson via 4D_Tech]

On Mon, Aug 7, 2017 at 3:00 PM,
​
​
David Adams  wrote:

>
>
> > How do you deal with that problem (Preventing duplicate data)
>

Definitely
​
"Carefully program your system to detect and prevent duplicate rows" as
appropriate. Generally such a Dupe Check can take many forms depending on
the business needs, the data in question, and the data entry
process/environment. I've not yet found a solution that fits all. Generally
it is much easier to do this if the "data entry user" is a browser post -
where you have the time and space to do more complicated look-ups. (More
and more of my own projects are web front ends to 4D in the backend.)
 ​I've used similar constructions as John's ContactsDuplicateManager example
as well, although I steer away from storing extra data if I can. For less
immediacy data needs I've found that after hours "helper" routines that
fire off and run in the background working through data to flag dupes for
admin oversight next day is popular with some managers who prefer to make
their own decision about whether some stuff really is a dupe or not. Some
duplicate data has to be eliminated "right now" before the record is saved;
whereas some might be interesting to investigate a little more in depth.
The whys and wherefores --what caused it, who caused it, where did it come
from, and why, is it legit or a real mistake; such questions can often lead
to better processes, better training, better form design, better import
provisioning, or better import pre-cleaning, etc. It all depends on the
project and biz needs.

Steve Simpson
**
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
**

​Re: UUID vs Longint primary key

[steve simpson via 4D_Tech]

On Mon, Aug 7, 2017 at 11:51 AM, <
​
<4d_tech-requ...@lists.4d.com>
​
npden...@greatext.com> wrote:

>
> ​[snip]
>
> On the other hand, you do model the data after business relations, but the
> keys that tie that relation data need/should never be seen in a well
> designed system. If a user readable key is needed by business, then there
> should be another data piece that the user can read (like an MRN, medical
> record number, or an abbreviation that is unique and human readable) But
> these should never be used to link together data in a structure in primary
> key foreign key relation.
> ​ [snip]​
>
>
>
+1 My point exactly, only stated much better.​
​
​

Steve Simpson
**
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
**

​Re: UUID vs Longint primary key

[steve simpson via 4D_Tech]

David and Chuck, point taken about "rows" being unique because of and
created with the containing data of each row -- up to a ... well "a point".
Like you said, a real pain when real world reality steps in. I believe the
only truism involved here is your statement that "...
​i
t then leaves the task of doing integrity checks and so on to you.
​" Exactly! Regardless of the way you decide to handle 4D record
uniqueness, you will surely encounter ​the ongoing need to continually
manage integrity "on your own". Hoping that your "unique key" will do that
for you is likely not realistic, regardless of your method.

I'm sure that many of us have had to eventually abandon the 4D long int
"auto increment" in favor of some sort of crafted version of it when we
expanded to mixing data sources. For instance, you build and distribute an
application that starts up out the gate with recordID #1, then #2, then #3,
etc with each install. But  5 years later the client wants everyone - all 4
thousand installs - to start sending data to a central accounting
processing point -- retaining uniqueness across the enterprise. Oooops.
Suddenly, you have to make sure that each and every installation has some
sort of retrofitted unique number, something not envisioned when it was
first developed. Whoa. Big problem.

I must say that the only "real" solution to this so far in the 4D world -
for me at least - has been the auto UUID key field. Finally a way to create
a record (and its children) that can be moved around willy-nilly without
angst. OK, granted it does not solve the issue of "integrity" from row to
row. But neither does your own example of finding uniqueness within each
row's actual data (i.e.
​
Keller123, 1
​
Keller123, 2
​
Keller123, etc); that is a task you have to deal with regardless of how you
handle your own unique key - logical ways - important realistic vertical
market biz logic ways -- issues that may be unique to each project -- logic
that may change over time. It has NOTHING to do with the record key in of
of itself. Chuck Miller said in response, "...
​
I am not David but I agree with his assessment. Relational model databases
by definition are not supposed to use keys that have no meaning. They are
supposed to create relations that have meaning". All I can say is that
"meaning" per row, and meaning contained within children rows -- especially
meaning to "humans" -- may not really exist and may have little to cling to
or may even change as projects expand and morph.

I'm really just reacting to what I experience as "theory" mismatch with
real world reality. We need to separate "record uniqueness" as an idea from
"meaning" of the data within a row, since no matter how you handle record
uniqueness you will still need to craft your own unique project needs to
insure "data integrity", which can take many forms and have many challenges
beyond some simple "row" logic. And realize that these needs will likely
change over time as the project morphs. So the first need is to handle "4D
record ID uniqueness". (and in my experience so far, ONLY UUIDs do that
satisfactorily.) Then address your project specific "data integrity" needs
and understand that you'll have to deal with that on an ongoing basis
regardless of how you handle record uniqueness as your app grows and morphs
and expands and begins to interact with other outside data sources.

And BTW, we all have users who get a lot of info from the visual feedback
of incremental "record numbers". OK, no problem. Just another field:
"record number", far different from "unique internal record KEYID". And
likely understandable and fixable for human needs if dupes are introduced
with data mergers. Just another "user comprehension data integrity" task.

Steve Simpson
​Cimarron Software

On Sun, Aug 6, 2017 at 3:00 PM, <4d_tech-requ...@lists.4d.com> wrote:

>
>
> Message: 3
> Date: Sun, 6 Aug 2017 11:03:57 -0400
> From: Chuck Miller 
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Subject: Re: ​
> ​​
> Re: UUID vs Longint primary key
>
> ​​
> I am not David but I agree with his assessment. Relational model databases
> by definition are not supposed to use keys that have no meaning. They are
> supposed to create relations that have meaning. Even the use of numbers
> breaks the theoretical rule. The problem is that we have pushed all to use
> relational model rather that what he logical model proposes. Who out there
> remembers hierarchical, tree, or inverted structure models.
>
> Regards
> Chuck
> --
>
> Message: 4
> Date: Sun, 6 Aug 2017 08:16:07 -0700
> From: David Adams 
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Subject: Re: ​Re: UUID vs Longint primary key
> ​[snip]
>
>
> When you design a relational database, you sort out the "keys" by finding
> the field or combination of fields in a table that make the row unique.


> Imagine that you've got an asset 

​Re: UUID vs Longint primary key

[steve simpson via 4D_Tech]

On  Fri, 4 Aug 2017 12:52:28 -0700
​
David Adams 
​ wrote:​

>
> ​[snip] ​
> 4D's UUIDs function as globally unique row *serial numbers*. That's great
> for backups and convenient for physical relations, but it has exactly zero
> to do with a real "primary key" or relational integrity.
> ​ [snip]​
>

​Care to elaborate on that statement? I don't get why you'd say that.​
_
Steve Simpson
**
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
**

Re: ​Someone help me out, how do you get good information out of 4D

[steve simpson via 4D_Tech]

>
> From: David Adams 
>
> For anyone that's seen me on the forums in recent months, let's just
> say...what I'm doing isn't working. I keep raising what I think are pretty
> basic issues and I just end up with a ton of heat back from 4D and not a
> lot of information. It's exhausting and renews my disgust.
> ​[snip]
>
> Advice appreciated, on-list or off. I know I tend to sound cranky and that
> can rub people the wrong way.
> ​[snip]
>

​David, I do not use the Fr. forums because I honestly cannot understand
them any better than you can evidently, nor get any real information from
them. Whether that is simply because I'm more used to this list, I can't
say, but that forum is totally inscrutable to me. So I'm not familiar with
the "heat" you receive over there.​ That said

I'm probably not alone in saying that I always look forward to your posts
here, whether they have anything to do with my own issues at the moment or
not. I always find some nugget that I find thought provoking or useful or
worthy of filing away for future use. And generally I just get a kick out
of your intellect and ability to delve deeply and let it all hang out. I do
find myself worrying about you sometimes though, as to whether you get
enough sleep, or just how healthy it might be to go so deep for so long on
this or that single issue. Maybe it is just that you are a way faster
typist than I am. But ... anyway...

I get the feeling that you use 4D (recently at least) for much different
projects than I (or most of us?) do. 4D to me, is not a "big data" kind of
product. To me it is more like an "office automation" product. A
secretarial pool type product. A company or departmental "get this work
done like THIS" type product. Whereas (at least recently) I get the
impression that you are trying to stuff 4D  into some sort of big data
manipulation role that might be a pretty frustrating task. And demanding
big data tools like you are needing these days might seem a bit off track
to the guys in France who have been making this "officey" kind of thing for
so many years. I see 4D's real strength in the developer's ability to craft
a really high end user interface. But recently you seem to have been
frustrated in it's inability to "scale" to something...different -- more
"headless" -- something I haven't yet figured out where you are going.

Big data dismissals above aside, I'm knee deep for the last two years in a
project to digitize USA county courthouses. That means millions and
millions and millions of scanned (and then digitized) court documents with
massive amounts of data stored in searchable fields whereby ordinary title
insurance secretarial types can find (and receive locally) documents they
need (for a closing for instance). This requires massive data stores with
really easy data access by normal non-tech type people. It requires an
extremely facile "database system" that the developer can use to craft
multitudes of import routines with a high level scripted environment (every
county court clerk has his own ideas about format), as well as an easy user
environment for legal expert tech staff to massage that data into usable
digital formats -- and an easy way to move that data to web environments to
make it available to the hoi polloi. So I understand your frustrations of
"big data" needs. (One single state county can entail 12+TB of assets
available to 4D!) On the other hand, I don't have to do much with that data
- no really complex slice and dice operations; no complicated accounting
mathematics; no historical comparison graphing operations, etc. Its "big"
data in many ways, but mundane data in most other ways, with most needs
tilted toward normal everyday user access. I just cannot find a better
platform for all of this together than 4D. (Though I'd be really interested
in those products you are turning to as I'm sure some of them might be
useful.) I could go in search of multiple products to handle all this data
-- but on the whole I want to keep my life simple with ONE product I know
really really well. When confronted with a project that would clearly
unambiguously demand other systems I'd have to learn well to succeed with,
I turn down that project. 4D is not for everything and everyone. Nor am I.
I decided long ago that I could not be everything for everyone so I
decided to be good with one thing and pretty thin on other things. Sort of
the opposite of your typical computer science program these days. And
somewhat different from your own quest lately to be really good at
EVERYTHING, it sometimes sounds like. That is what I love about your posts,
but what I also worry about for you when I read those long beautiful emails
you send out. Like your brain is on overdrive. Like I could never get work
done and write that much unless I never slept and was a super fast typist.
I admire that about you.

But... to get back to your core point, I think you are demanding that
France come up with a product that 

​Re: How to detect EOL character in text file

[steve simpson via 4D_Tech]

On Sat, May 13, 2017 at 9:04 AM,
​
​
Peter Mew  wrote:
>
>
> Replace text($text;lf;cr)
> Replace text($text;crlf;cr)
> Position($text;cr)
>

​+1. I find this the fastest and simplest method of handling high volumes
of incoming "unknown" or "known to be dirty" or "suspect" text. (And not
just to find an EOL.) Plus you can't always use something like ​"Document
to text" as the initial spigot point. And by the way, some incoming text
contains actual text like "/r" that does not immediately equate to char(13)
assumed above, which is just as easily handled with "replace text".


Steve Simpson
​Cimarron Software
**
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
**

​Re: Schemes for record level access control

[steve simpson via 4D_Tech]

On Sat, May 13, 2017 at 9:04 AM,
​
​
 David Adams  wrote:
>
>
> Just as a simple point, it's nice to have access values as a number:
>
> 1 2 3 4 5
>
> Imagine that access increases at each step.
>
> // On after query
> C_LONGINT($1;$user_access_level)
> $user_access_level:=$1
>
> QUERY SELECTION([Foo];[Foo]Minimum_access_score <= $user_access_level)
>

​+1​, especially when "...then you don't have to jump through any more
hoops when using 4D's built-in editors and tools.
​"​



Steve Simpson
​Cimarron Software
**
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
**

​Re: Clean Slate - Modern User Experience

[steve simpson via 4D_Tech]

> On Apr 17, 2017, at 8:47 AM,Peter Jakobsson wrote:
>
> > Doesn’t the O/S define ‘modern era’ ?
> >
> > If you stick to vanilla 4D objects (i.e. just the raw button styles,
> list styles & fields etc) then the O/S will do all the work for you in
> keeping your screens up to date.
>

​+1​


Steve Simpson
​Cimarron Software
**
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
**

Re: ​Please vote for this feature request: Raise the 31 character limit

[steve simpson via 4D_Tech]

On Mon, Mar 6, 2017 at 3:00 PM,
​
Keith Goebel  wrote:

> ​[snip]
>
> Curious interface...
>

Understatement!​


Steve Simpson
​Cimarron Software
**
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
**

Re: Please vote for this feature request: Raise the 31 character limit

[steve simpson via 4D_Tech]

On Sun, Mar 5, 2017 at 3:00 PM,
​David Adams
 wrote:

> Please vote for this feature request: Raise the 31 character
>   limit (David Adams)
>

​uh... Do you mean for variable names?  nah... no thanks. Can't
remember the last time I felt constrained by a 31 char limit. In fact,
reading code with a bunch of variable names approaching 20 char makes my
blood pressure go up.​ The worst for me is meaningless variable names. The
next worst thing for me is really long variable names that could use some
smart concise editing that retains meaning with readability.


Steve Simpson
​Cimarron Software
**
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
**