Re: 4D Write for v17

[Bernd Fröhlich via 4D_Tech]

Mitchell Shiller:

> Where do I get a v17 version of the old 4D Write to run in 32 bit mode? Must 
> be having a brain cramp cause I don’t see it on the website.

It is a "little" bit hidden:

there is a tiny note at the bottom in light blue that says "Note about 4D v17 
32-bit versions" which will take you to another site with a lot of text and a 
link to the download at the end of the text.

I am running 4D V17 32 bit over here with 4D Write and WritePro side by side 
during the conversion.
No big problems so far. (Except that WritePro is a big pita to program but I 
guess I will have to get used to it.)

Greetings from Germany,
Bernd Fröhlich
**
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: Coding/Development Style Guide?

[Tom Benedict via 4D_Tech]

> On Dec 16, 2018, at 14:24, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Remember what they say, there are only 2 hard things in writing code:
> naming things, clearing the cache and the off-by-one problem.
> 
That reminds me a signature I’ve seen thousands of times here. "There are three 
kinds of mathematicians, those who can count and those who can’t.

Tom Benedict
**
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: Coding/Development Style Guide?

[Dani Beaubien via 4D_Tech]

This says it all...
https://www.itworld.com/article/2823759/enterprise-software/124383-Arg-The-9-hardest-things-programmers-have-to-do.html#slide10
 

Dani Beaubien
Open Road Development

> On Dec 16, 2018, at 3:24 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I agree with Peter. Object names need to convey what their purpose is, at
> best, and be as unambiguous as possible at least. The size of the method
> has a lot to do with how ambiguous a name might be. I have no qualms about
> using $i as an index counter in a method where there is only one loop or
> it's only a few lines long. It's really simple to rename variables if the
> method starts to go long.
> 
> I've seen plenty of code with long var names, type appended, that are just
> as difficult to read as code with abstruse names and no system. Personally
> I think confusing naming schemes arise when the overall purpose of the code
> is lost or poorly defined. A little time making sure we know what we are
> doing might be more productive than typing long variables names.
> 
> Remember what they say, there are only 2 hard things in writing code:
> naming things, clearing the cache and the off-by-one problem.
> 
> On Sun, Dec 16, 2018 at 2:08 PM Peter Bozek via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
> 
>> On Sun, Dec 16, 2018 at 10:15 PM B.Bippus via 4D_Tech <
>> 4d_tech@lists.4d.com>
>> wrote:
>> 
>>> Begin each variable name with a character to specify what type it is:
>>> · String: s
>>> · Text: t
>>> · Boolean: y
>>> 
>>> To add the Variable Type to the Variablename is a big help. I started
>> many
>>> years ago to prepend the Type. And I am using the "4D Pop Marco
>>> Declaration" to automatically declare every variable. (I have a complete
>>> Regex Setup for prepending the Type if someone need it).
>>> 
>>> But in the last days I am thinking if it would have been better to append
>>> the Type: For example: $t_Name  vs.  $Name_t.
>>> So if you are starting with a variable-name convention: Think about it
>>> first.
>>> 
>>> And because of the Object-Tag names are case-sensitive, it makes sense to
>>> have a convention for the Object-Tag names too. I use: every Name-Part
>>> starts with a uppercase character and the rest is lowercase. Example
>> Tags :
>>> "Last_Changed" , "Simple_Tag".
>>> 
>>> My variable naming conventions :
>>> C_LONGINT($l_WinRef)
>>> C_OBJECT($o_parameter_3)
>>> C_REAL($r_Amount)
>>> C_TEXT($t_Customer_Code)
>>> C_BOOLEAN($b_ok)
>>> C_DATE($d_Budgets_End_Date)
>>> C_OBJECT($o_Parameter)
>>> C_POINTER($p_Table)
>>> C_Blob($bl_Var)
>>> 
>>> ARRAY LONGINT($al_Budgets_Code;0)
>>> ARRAY REAL($ar_Sum_of_Trades;0)
>>> 
>> 
>> I will offer a contrarian view: Some time ago, I was using the same
>> notation (Camel one, but that is detail) but now I decided against it.
>> 
>> I maintain several databases for a long time, so so I have a lot of
>> variables with 's' prefix, what is now text. This is not a big problem, I
>> can understand that 's' and 't' means the same, but it still disturb me a
>> bit. But with integer prefix i had a dilemma, as integer arrays still
>> exists and need to be used with integer fields, so I rather redeclared and
>> renamed all integer variables and arrays with 'l', but are still unsure
>> when I see 'ai' prefix in some old code - did I forgot to redeclare and
>> rename it, or is it still an integer (and should it be changed to longint?)
>> 
>> Second, as I often work with code written by different developer, mix of
>> various styles lead to not really well readable code. And I hate variable
>> names like $day_D (or, even better, $d_D) or $index_L etc. It provides no
>> information and makes the code ugly and unreadable. (Besides, does not 4D
>> now show variable type as cursor hoover above it?)
>> 
>> I now try to provide clear and readable variable names, without prefixes or
>> postfixes. This means I would have
>> C_LONGINT($winRef)
>> C_REAL($amount)
>> C_TEXT($customerCode)
>> 
>> I still use prefix when the type of variable is different from what the
>> name would suggest, but I prefer, when possible, names like $tablePtr;
>> $tableNo and $tableName to $p_table, $l_table and $t_table. I would still
>> use
>> C_BOOLEAN($bOK) but
>> C_LONGINT($OK)
>> 
>> I would still use
>> C_OBJECT($oParameter2)
>> but would try avoid such names.
>> 
>> Such names lead to readable code - like
>> For($index;1;$size)
>>  $sum:=$sum+$amount
>> ...
>> works well with other notations, and are easier to write.
>> 
>> --
>> 
>> Peter Bozek
>> 
> -- 
> Kirk Brooks
> San Francisco, CA
> ===
> 
> *We go vote - they go home*
> **
> 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: Coding/Development Style Guide?

[Kirk Brooks via 4D_Tech]

I agree with Peter. Object names need to convey what their purpose is, at
best, and be as unambiguous as possible at least. The size of the method
has a lot to do with how ambiguous a name might be. I have no qualms about
using $i as an index counter in a method where there is only one loop or
it's only a few lines long. It's really simple to rename variables if the
method starts to go long.

I've seen plenty of code with long var names, type appended, that are just
as difficult to read as code with abstruse names and no system. Personally
I think confusing naming schemes arise when the overall purpose of the code
is lost or poorly defined. A little time making sure we know what we are
doing might be more productive than typing long variables names.

Remember what they say, there are only 2 hard things in writing code:
naming things, clearing the cache and the off-by-one problem.

On Sun, Dec 16, 2018 at 2:08 PM Peter Bozek via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> On Sun, Dec 16, 2018 at 10:15 PM B.Bippus via 4D_Tech <
> 4d_tech@lists.4d.com>
> wrote:
>
> > Begin each variable name with a character to specify what type it is:
> > · String: s
> > · Text: t
> > · Boolean: y
> >
> > To add the Variable Type to the Variablename is a big help. I started
> many
> > years ago to prepend the Type. And I am using the "4D Pop Marco
> > Declaration" to automatically declare every variable. (I have a complete
> > Regex Setup for prepending the Type if someone need it).
> >
> > But in the last days I am thinking if it would have been better to append
> > the Type: For example: $t_Name  vs.  $Name_t.
> > So if you are starting with a variable-name convention: Think about it
> > first.
> >
> > And because of the Object-Tag names are case-sensitive, it makes sense to
> > have a convention for the Object-Tag names too. I use: every Name-Part
> > starts with a uppercase character and the rest is lowercase. Example
> Tags :
> > "Last_Changed" , "Simple_Tag".
> >
> > My variable naming conventions :
> > C_LONGINT($l_WinRef)
> > C_OBJECT($o_parameter_3)
> > C_REAL($r_Amount)
> > C_TEXT($t_Customer_Code)
> > C_BOOLEAN($b_ok)
> > C_DATE($d_Budgets_End_Date)
> > C_OBJECT($o_Parameter)
> > C_POINTER($p_Table)
> > C_Blob($bl_Var)
> >
> > ARRAY LONGINT($al_Budgets_Code;0)
> > ARRAY REAL($ar_Sum_of_Trades;0)
> >
>
> I will offer a contrarian view: Some time ago, I was using the same
> notation (Camel one, but that is detail) but now I decided against it.
>
> I maintain several databases for a long time, so so I have a lot of
> variables with 's' prefix, what is now text. This is not a big problem, I
> can understand that 's' and 't' means the same, but it still disturb me a
> bit. But with integer prefix i had a dilemma, as integer arrays still
> exists and need to be used with integer fields, so I rather redeclared and
> renamed all integer variables and arrays with 'l', but are still unsure
> when I see 'ai' prefix in some old code - did I forgot to redeclare and
> rename it, or is it still an integer (and should it be changed to longint?)
>
> Second, as I often work with code written by different developer, mix of
> various styles lead to not really well readable code. And I hate variable
> names like $day_D (or, even better, $d_D) or $index_L etc. It provides no
> information and makes the code ugly and unreadable. (Besides, does not 4D
> now show variable type as cursor hoover above it?)
>
> I now try to provide clear and readable variable names, without prefixes or
> postfixes. This means I would have
> C_LONGINT($winRef)
> C_REAL($amount)
> C_TEXT($customerCode)
>
> I still use prefix when the type of variable is different from what the
> name would suggest, but I prefer, when possible, names like $tablePtr;
> $tableNo and $tableName to $p_table, $l_table and $t_table. I would still
> use
> C_BOOLEAN($bOK) but
> C_LONGINT($OK)
>
> I would still use
> C_OBJECT($oParameter2)
> but would try avoid such names.
>
> Such names lead to readable code - like
> For($index;1;$size)
>   $sum:=$sum+$amount
> ...
> works well with other notations, and are easier to write.
>
> --
>
> Peter Bozek
>
-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
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: Coding/Development Style Guide?

[Peter Bozek via 4D_Tech]

On Sun, Dec 16, 2018 at 10:15 PM B.Bippus via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Begin each variable name with a character to specify what type it is:
> · String: s
> · Text: t
> · Boolean: y
>
> To add the Variable Type to the Variablename is a big help. I started many
> years ago to prepend the Type. And I am using the "4D Pop Marco
> Declaration" to automatically declare every variable. (I have a complete
> Regex Setup for prepending the Type if someone need it).
>
> But in the last days I am thinking if it would have been better to append
> the Type: For example: $t_Name  vs.  $Name_t.
> So if you are starting with a variable-name convention: Think about it
> first.
>
> And because of the Object-Tag names are case-sensitive, it makes sense to
> have a convention for the Object-Tag names too. I use: every Name-Part
> starts with a uppercase character and the rest is lowercase. Example Tags :
> "Last_Changed" , "Simple_Tag".
>
> My variable naming conventions :
> C_LONGINT($l_WinRef)
> C_OBJECT($o_parameter_3)
> C_REAL($r_Amount)
> C_TEXT($t_Customer_Code)
> C_BOOLEAN($b_ok)
> C_DATE($d_Budgets_End_Date)
> C_OBJECT($o_Parameter)
> C_POINTER($p_Table)
> C_Blob($bl_Var)
>
> ARRAY LONGINT($al_Budgets_Code;0)
> ARRAY REAL($ar_Sum_of_Trades;0)
>

I will offer a contrarian view: Some time ago, I was using the same
notation (Camel one, but that is detail) but now I decided against it.

I maintain several databases for a long time, so so I have a lot of
variables with 's' prefix, what is now text. This is not a big problem, I
can understand that 's' and 't' means the same, but it still disturb me a
bit. But with integer prefix i had a dilemma, as integer arrays still
exists and need to be used with integer fields, so I rather redeclared and
renamed all integer variables and arrays with 'l', but are still unsure
when I see 'ai' prefix in some old code - did I forgot to redeclare and
rename it, or is it still an integer (and should it be changed to longint?)

Second, as I often work with code written by different developer, mix of
various styles lead to not really well readable code. And I hate variable
names like $day_D (or, even better, $d_D) or $index_L etc. It provides no
information and makes the code ugly and unreadable. (Besides, does not 4D
now show variable type as cursor hoover above it?)

I now try to provide clear and readable variable names, without prefixes or
postfixes. This means I would have
C_LONGINT($winRef)
C_REAL($amount)
C_TEXT($customerCode)

I still use prefix when the type of variable is different from what the
name would suggest, but I prefer, when possible, names like $tablePtr;
$tableNo and $tableName to $p_table, $l_table and $t_table. I would still
use
C_BOOLEAN($bOK) but
C_LONGINT($OK)

I would still use
C_OBJECT($oParameter2)
but would try avoid such names.

Such names lead to readable code - like
For($index;1;$size)
  $sum:=$sum+$amount
...
works well with other notations, and are easier to write.

-- 

Peter Bozek
**
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: Coding/Development Style Guide?

[B.Bippus via 4D_Tech]

Begin each variable name with a character to specify what type it is:
· String: s
· Text: t
· Boolean: y

To add the Variable Type to the Variablename is a big help. I started many
years ago to prepend the Type. And I am using the "4D Pop Marco
Declaration" to automatically declare every variable. (I have a complete
Regex Setup for prepending the Type if someone need it).

But in the last days I am thinking if it would have been better to append
the Type: For example: $t_Name  vs.  $Name_t.
So if you are starting with a variable-name convention: Think about it
first.

And because of the Object-Tag names are case-sensitive, it makes sense to
have a convention for the Object-Tag names too. I use: every Name-Part
starts with a uppercase character and the rest is lowercase. Example Tags :
"Last_Changed" , "Simple_Tag".

My variable naming conventions :
C_LONGINT($l_WinRef)
C_OBJECT($o_parameter_3)
C_REAL($r_Amount)
C_TEXT($t_Customer_Code)
C_BOOLEAN($b_ok)
C_DATE($d_Budgets_End_Date)
C_OBJECT($o_Parameter)
C_POINTER($p_Table)
C_Blob($bl_Var)

ARRAY LONGINT($al_Budgets_Code;0)
ARRAY REAL($ar_Sum_of_Trades;0)


Bernd


PS: be careful with arrays and "4D Pop Marco Declaration": It moves the
declaration to the top of your Method. Use ARRAY
LONGINT($al_Budgets_Code;0x000)  to prevent it.

PPS: A Collegue uses the "4D Pop Marco Declaration" in a complete another
manner: He declares every variable by hand and then he uses the 4D Pop to
find every untyped or mistyped Variable. It works this way because he has
no "4D Pop Marco Declaration" setup for his convention.






Am Fr., 14. Dez. 2018 um 16:28 Uhr schrieb Tom Benedict via 4D_Tech <
4d_tech@lists.4d.com>:

> Anybody out there have a style guide for development that they’ve written?
> I know a lot of people use shells that either they or others have written
> and that goes a long way toward supporting ease of maintenance of an app.
> Have you formalized guidelines on coding style, UI standards, naming
> conventions etc? I’m especially looking for examples that have worked well
> in team development.
>
> Thanks for any input.
>
> Tom Benedict
> **
> 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
> **
**
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: Annoying square

[Jeremy French via 4D_Tech]

Hi Carl,

The 4D iNUG list is plain text only. (That’s why your screen shot wasn’t 
published.)

But you can share images on the list (indirectly) by providing a link to the 
image.

See https://postimages.org  which offers free image 
posting.

Just upload your screenshot (at above URL). Then post the screenshot’s URL on 
the iNUG.

You can actually publish images in the body of your post when using 4D’s forum 
at:
http://forums.4d.com/MyHome/EN

Regards,

Jeremy



> On Dec 16, 2018, at 6:47 AM, Carl Aage Wangel via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> …previously sent a screenshot but it wasn't published on the list (for 
> whatever reason)…

**
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: Annoying square

[Carl Aage Wangel via 4D_Tech]

Thanks Helge, Tim and Keisuke for the response.

I have previously sent a screenshot but it wasn't published on the list (for
whatever reason). I am on Windows 7 (mainly) with splash window visible. I
am trying with  and will see how it goes. On top of the
ordinary splash screen I am using my own with New process and dialog.

Regards

Carl

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