Re: Horizontal Sizing Move

[Robert Livingston via 4D_Tech]

Thanks for taking time to reply.

In my case, the button is the only item in the header. The output form itself 
was just created in the Wizard. During editing I remove all the button in the 
header except for my cancel button which I place in the upper right of the 
header.

Basically, that button will move to the right if the window is widened but will 
not move much to the left if the window is narrowed. Rather it just disappears 
from view.

I am not sure what the "static objects" are.


> On Jun 17, 2017, at 10:59 AM, Pat Bensky via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I think it depends  on whatever static objects are on the form. If you've
> got an object that is not set to move, that will form the boundary for
> resizing purposes.

**
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: Modal dialog dilemma

[Pat Bensky via 4D_Tech]

Thanks for your thoughtful and detailed reply Jody. I will experiment with
your suggestions.

I did a quick test of deleting the variable names for the Save and Cancel
buttons on the affected forms ... didn't help ):

We're in the process of moving to v16 but in the mean time ... stuck on v13.

Pat

On 17 June 2017 at 22:35, Jody Bevan via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Pat:
>
> ‘Bleed Through’ or as I have called it the ‘Butteryfly Effect’, has always
> been a nasty surprise and something that takes experience (and discipline)
> in large systems to not bite you from time to time. I know I have been
> bitten too many times. Pat without knowing for certain why this is
> happening to you I will discuss what we are doing to prevent this from
> happening at least with one cause.
>
> We are rewriting our starting shell at this time. The bleed through is
> something we are trying to set up the shell to never have. Bold statement
> ‘never’. There are a few things that we are using to put the stop to this:
>
> 1. On all forms we never use variables. This is a very big step to help
> prevent this. Therefore the Accept or Cancel buttons on forms are never
> having the same name (well not likely to have the same name). This means
> that the ‘Accept’ button on one form in the same process does not get a
> value and it bleeds through to the other form(s).
>
> 2. We have a generic form that has several objects on it. At runtime we
> will make objects visible or not, and change their titles, positions, etc.
> This permits us to have one form that handles Alerts, Requests, and
> Confirms. We provide more features than that with these dialogs (like help
> buttons, trace, etc). This means this dialog gets used extensively. To date
> we have not found any bleed through from it.
>
> 3. In our code we do not use Process Variables (and about 15 Interprocess
> Variables). This goes a long way to reduce bleed through from one process
> method/form into another.
>
> 4. Dialogs that a process call up though will need to get the input from
> the user. We accomplish this through an object we call our Process Object.
> Inside the process object a object is created for every running process.
> When a form is opened within the process an object is created for that
> form. When a dialog is opened an object is created within that form object.
> There we set what all the dialog objects are to be, and we also return the
> results from the user input. The form that called the dialog gets the
> information it is looking for from this object. Once the information is
> obtained that dialog object is deleted from memory.
>
> It seems complex and it would be if we had to write the code each time. We
> have written nice generic methods for its use. We also created macros as we
> do for all this stuff that makes it very quick to build a request dialog
> (for example) in our code.
>
> To date we have not seen any bleed through. This was the main reason for
> developing this type of dialog.
>
> In Summary:
>
> 1. Writing code without any Process Variables on Forms.
> 2. Writing code with a very limited use of Interprocess Variables.
> 3. Always using named objects rather than variables on Forms.
> 4. Using Objects extensively.
>
> This is a code style we started back in 2004, but having the advantage of
> starting a shell from scratch in v15 (now v16R2) we have carried the above
> 4 goals to the maximum extreme. One of the reasons for this was ‘Bleed
> through’, which we have not seen to date. The design expectation is that it
> should be impossible for it to happen.
>
> From your description, it is my opinion that this is something you could
> implement in your code (as long as you use 4D v12 or greater) to resolve
> the issue within the limited scope you describe. As you learn to like it,
> then you could expand it as you have time to rewrite old code, and in
> anything new that your write.
>
> Jody
>
>
> > On Jun 17, 2017, at 9:53 AM, Pat Bensky via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
> >
> > Using v 13.5 ...
> >
> > I have a modal dialog which displays info from [Table A] and contains a
> > pop-up menu listing items form [Table B]. Sometimes it is necessary to
> > modify a [Table B] record, or add a new one, within that dialog. So we
> > change the window size (if necessary), find the record to be edited, or
> > create a new one, edit it and then either Save or Cancel, then resize the
> > window back to what it was (if necessary) and redisplay the original
> [Table
> > A] form. For the most part this works fine. However in some circumstances
> > the Save or Cancel from the second form "bleeds through" to the first one
> > and the dialog window closes. We have to have an ACCEPT or CANCEL in the
> > second form otherwise it won't unload.
> >
> > Specifically, if a [Table B] record is edited - no problem. But if a new
> > [Table B] record is created and then edited - without saving the [Table
> A]
> > record first - then we have the 

Re: Modal dialog dilemma

[Jody Bevan via 4D_Tech]

Pat:

‘Bleed Through’ or as I have called it the ‘Butteryfly Effect’, has always been 
a nasty surprise and something that takes experience (and discipline) in large 
systems to not bite you from time to time. I know I have been bitten too many 
times. Pat without knowing for certain why this is happening to you I will 
discuss what we are doing to prevent this from happening at least with one 
cause.

We are rewriting our starting shell at this time. The bleed through is 
something we are trying to set up the shell to never have. Bold statement 
‘never’. There are a few things that we are using to put the stop to this:

1. On all forms we never use variables. This is a very big step to help prevent 
this. Therefore the Accept or Cancel buttons on forms are never having the same 
name (well not likely to have the same name). This means that the ‘Accept’ 
button on one form in the same process does not get a value and it bleeds 
through to the other form(s).

2. We have a generic form that has several objects on it. At runtime we will 
make objects visible or not, and change their titles, positions, etc. This 
permits us to have one form that handles Alerts, Requests, and Confirms. We 
provide more features than that with these dialogs (like help buttons, trace, 
etc). This means this dialog gets used extensively. To date we have not found 
any bleed through from it. 

3. In our code we do not use Process Variables (and about 15 Interprocess 
Variables). This goes a long way to reduce bleed through from one process 
method/form into another. 

4. Dialogs that a process call up though will need to get the input from the 
user. We accomplish this through an object we call our Process Object. Inside 
the process object a object is created for every running process. When a form 
is opened within the process an object is created for that form. When a dialog 
is opened an object is created within that form object. There we set what all 
the dialog objects are to be, and we also return the results from the user 
input. The form that called the dialog gets the information it is looking for 
from this object. Once the information is obtained that dialog object is 
deleted from memory.

It seems complex and it would be if we had to write the code each time. We have 
written nice generic methods for its use. We also created macros as we do for 
all this stuff that makes it very quick to build a request dialog (for example) 
in our code.

To date we have not seen any bleed through. This was the main reason for 
developing this type of dialog. 

In Summary:

1. Writing code without any Process Variables on Forms.
2. Writing code with a very limited use of Interprocess Variables.
3. Always using named objects rather than variables on Forms.
4. Using Objects extensively.

This is a code style we started back in 2004, but having the advantage of 
starting a shell from scratch in v15 (now v16R2) we have carried the above 4 
goals to the maximum extreme. One of the reasons for this was ‘Bleed through’, 
which we have not seen to date. The design expectation is that it should be 
impossible for it to happen.

From your description, it is my opinion that this is something you could 
implement in your code (as long as you use 4D v12 or greater) to resolve the 
issue within the limited scope you describe. As you learn to like it, then you 
could expand it as you have time to rewrite old code, and in anything new that 
your write.

Jody


> On Jun 17, 2017, at 9:53 AM, Pat Bensky via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Using v 13.5 ...
> 
> I have a modal dialog which displays info from [Table A] and contains a
> pop-up menu listing items form [Table B]. Sometimes it is necessary to
> modify a [Table B] record, or add a new one, within that dialog. So we
> change the window size (if necessary), find the record to be edited, or
> create a new one, edit it and then either Save or Cancel, then resize the
> window back to what it was (if necessary) and redisplay the original [Table
> A] form. For the most part this works fine. However in some circumstances
> the Save or Cancel from the second form "bleeds through" to the first one
> and the dialog window closes. We have to have an ACCEPT or CANCEL in the
> second form otherwise it won't unload.
> 
> Specifically, if a [Table B] record is edited - no problem. But if a new
> [Table B] record is created and then edited - without saving the [Table A]
> record first - then we have the bleed-through problem.
> 
> Note that when a new [Table B] record is added in this way, it's saved
> before it can be edited - so it isn't a new record when it is edited. I
> can't figure out why this behaves differently for a newly added record! Any
> ideas?
> 
> Thanks
> Pat
> 
> -- 
> *
> CatBase - The Database Publishing Solution
> tel: +44 (0) 207 118 7889
> w: http://www.catbase.com
> skype: pat.bensky
> 

Re: Horizontal Sizing Move

[Pat Bensky via 4D_Tech]

Robert,
I think it depends  on whatever static objects are on the form. If you've
got an object that is not set to move, that will form the boundary for
resizing purposes.
If you have more than one page on the form, it will take into account
objects on ALL pages.

HTH
Pat

On 17 June 2017 at 17:08, Robert Livingston via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> I am confused by an apparent restriction.
>
> Mac os
>
> 4D version: 16 R2
>
> When I create a list view (say 1400 pixels wide) and it is resizable then
> the user can grab the right lower corner and resize the window. If they
> make it very narrow then more and more information of the various listed
> records gets hidden. If they make it very wide, the rightmost field expands
> to take advantage of the space made available. This is fine and expected.
>
> My problem is with a button in the header. In the design environment, I
> set it at the upper right of the window. I set its property to Horizontal
> Sizing: Move.
>
> If I make the window, very wide then the button keeps up traveling to the
> right as I would want.
>
> If I start to make the window narrow, then at first the button behaves as
> I would like. It travels to the left so as to stay in view. But then it
> "stops" and as I make the window narrower, it disappears from view. I am
> not making the window some bizarre extremely narrow thing. There is nothing
> in the header that is "in the way"
>
> Is there some setting that I do not understand that I have applied to make
> the button refuse to move further to the left? How does 4D decide just
> where it is going to stop letting the button move as the user shrinks the
> window?
> **
> 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
> **




-- 
*
CatBase - The Database Publishing Solution
tel: +44 (0) 207 118 7889
w: http://www.catbase.com
skype: pat.bensky
*
**
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
**

Horizontal Sizing Move

[Robert Livingston via 4D_Tech]

I am confused by an apparent restriction.

Mac os

4D version: 16 R2

When I create a list view (say 1400 pixels wide) and it is resizable then the 
user can grab the right lower corner and resize the window. If they make it 
very narrow then more and more information of the various listed records gets 
hidden. If they make it very wide, the rightmost field expands to take 
advantage of the space made available. This is fine and expected.

My problem is with a button in the header. In the design environment, I set it 
at the upper right of the window. I set its property to Horizontal Sizing: 
Move. 

If I make the window, very wide then the button keeps up traveling to the right 
as I would want.

If I start to make the window narrow, then at first the button behaves as I 
would like. It travels to the left so as to stay in view. But then it "stops" 
and as I make the window narrower, it disappears from view. I am not making the 
window some bizarre extremely narrow thing. There is nothing in the header that 
is "in the way" 

Is there some setting that I do not understand that I have applied to make the 
button refuse to move further to the left? How does 4D decide just where it is 
going to stop letting the button move as the user shrinks the window?
**
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
**

Modal dialog dilemma

[Pat Bensky via 4D_Tech]

Using v 13.5 ...

I have a modal dialog which displays info from [Table A] and contains a
pop-up menu listing items form [Table B]. Sometimes it is necessary to
modify a [Table B] record, or add a new one, within that dialog. So we
change the window size (if necessary), find the record to be edited, or
create a new one, edit it and then either Save or Cancel, then resize the
window back to what it was (if necessary) and redisplay the original [Table
A] form. For the most part this works fine. However in some circumstances
the Save or Cancel from the second form "bleeds through" to the first one
and the dialog window closes. We have to have an ACCEPT or CANCEL in the
second form otherwise it won't unload.

Specifically, if a [Table B] record is edited - no problem. But if a new
[Table B] record is created and then edited - without saving the [Table A]
record first - then we have the bleed-through problem.

Note that when a new [Table B] record is added in this way, it's saved
before it can be edited - so it isn't a new record when it is edited. I
can't figure out why this behaves differently for a newly added record! Any
ideas?

Thanks
Pat

-- 
*
CatBase - The Database Publishing Solution
tel: +44 (0) 207 118 7889
w: http://www.catbase.com
skype: pat.bensky
*
**
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: Website development path

[Douglas Cryer via 4D_Tech]

Joshua,

I read a post you made in January (below).  I am currently building out a REST 
interface for a system.  I am finding writing the REST calls fun and 
challenging but the 4D language has a lot of stuff that helps.  What I am not 
having much fun with is the documentation.  I know what I want to document but 
I am not sure what the best approach is.

I read Swagger all the time although some of the documentation I have seen 
where the developers say they have used Swagger is frankly not that great.  I 
am not sure how I would use Swagger with hand coded 4D REST calls.  Do you have 
any guidelines or advice?  I think it might be just about getting some good 
templates which is not my strongpoint.

Regards,  Dougie

> On 16 Jan 2017, at 20:00, 4d_tech-requ...@lists.4d.com wrote:
> 
> We wrote a REST API in 4D and expose it with the built in web server.  The 
> REST API serves up JSON docs formatted in Siren.  The API is documented in 
> Swagger. On the front end we wrote an AngularJS application that talks to the 
> REST API.
> 
> Advantages:
> * If we wanted to we could implement the same API somewhere else and the 
> front end would keep working. There isn't anything 4D-specific about the web 
> app.
> * Our customers can access the REST API directly and build their own tools 
> (and a few of them are!).
> 
> Disadvantages:
> * Creating a REST API in 4D is time consuming. There aren't any 
> tools/frameworks to make this happen or to automatically generate 
> documentation, etc.
> 
> I found these two books to be very helpful:
> AngularJS Up and Running: http://shop.oreilly.com/product/0636920033486.do 
> 
> RESTful Web APIs: http://shop.oreilly.com/product/0636920028468.do 
> 
> 
> Joshua Hunter



telekinetix Limited- J. Douglas Cryer
Phone : 01234 761759  Mobile : 07973 675 218
2nd Floor Broadway House, 4-6 The Broadway, Bedford MK40 2TE
Email : jdcr...@telekinetix.com   Web : 
http://www.telekinetix.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
**