[BR_forum] BR 4.2 - ready for primetime?

George Tisdale · Post by **George Tisdale** » Wed May 13, 2009 10:02 am

Now, if all they do is type, and never activate an event like enter of FKEY yes the no parent will stay in the background and you will not see it. If however, they click on any BR screen in the session, or do something that causes and Fkey event the focus window will pop to the front. Your user before calling you would most likely have hit enter or clicked a screen to find out why he was “frozen”. As soon as he did POOF the focus window pops to the front.

In my example the CHILD window button creates a noparent screen that has one field in it and closes if you press enter. Your description I believe refers to this sample (which was a quick and dirty test never designed to cover the foibles of a real user situation) were you to change line 4043 to

04250 IF NOT (FK=99 OR FK=93) THEN GOTO 4040

You would see that although typing can be done by hiding the screen (only clicking on the border of the main screen not the screen itself, will hide the screen) as soon as enter or click happens the window pops to the front. No more hidden window.

George L. Tisdale, CPA

Post by **gordon** » Wed May 13, 2009 10:24 am

Given the fact that the new window positioning scheme has not been published yet, I suggest that we wait until that is available before proceeding with further testing of independent windows.

gordon

John · Post by **John** » Wed May 13, 2009 10:47 am

Shouldn’t parent=none windows be modal??? I can’t imagine a situation in which you wouldn’t want them to be modal.

And modal windows – when their parent gets focus the focus is instantly shifted to the modal child, there’s no waiting for an action, it just shifts the focus on focus.

Is there a situation where you would want a parent=none window to be non-modal? How you you process that in BR? Am I missing something or does parent=none non-modal windows just not make sense?

-john

Gabriel · Post by **Gabriel** » Wed May 13, 2009 11:04 am

There are many uses for Non-Modal windows. But you're right, there is no easy way to achieve that from BR. Its possible using FKEYS and complicated logic but its VERY tricky.

Gabriel

Post by **Susan Smith** » Wed May 13, 2009 11:07 am

I have situations where a user is entering information on a parent window and they need reference information to pull up while they are typing. That would be a perfect application for a non-modal window since they can move it out of the way and yet still see it while they go back to entering data on the underlying window. Then when you close the parent (or rather, the underlying window), you can then close the modal window too (with two different close statements since the non-modal window is technically not tied to that parent window at all...you know, being "Parent=none" and all...)

For those who don't know what modal means...
A modal window requires that the user interact with it FIRST before going back to the underlying window. Dialog boxes or warning windows are perhaps the best examples of modal windows because they usually pop up and require that you answer or cancel them before you can get back to the underlying window. Windows that can be open simultaneously while allowing the user to freely go back and forth between them are called non-modal or modeless. I knew that my college education would benefit me someday...

And I hope I got it right!

-- Susan

Gabriel · Post by **Gabriel** » Wed May 13, 2009 11:15 am

Hey, thats a good point! I can see a use for PARENT=NONE windows even the way they work now, as long as the user doesn't interact with them. If I am just opening a window up to display reference information, I can do it in a PARENT=NONE child window, and they're free to open or close it as they want to.

Gabriel

Post by **Susan Smith** » Wed May 13, 2009 11:49 am

That's right! I have loads of time when this would be handy!

-- Susan

John · Post by **John** » Wed May 13, 2009 12:33 pm

How could this work with only one thread? I mean – your input logic for the parent window (GUI Console) has to detect all clicks on the non-modal child and deal with them? what if you wanted to allow them to type into both? Would that be theoretically possible?

Gabriel · Post by **Gabriel** » Wed May 13, 2009 1:05 pm

Your input for the child window would detect any clicks on the parent window and then pass control (like GOTO) back to the parent window's logic. Then the Parent Windows logic would also have to detect any clicks on the child window and pass control back to the Child Windows Logic.

You could not have your users type into both at the same time without detecting the click and switching between them.

Thats what I mean by "Its complicated".

Gabriel

John · Post by **John** » Wed May 13, 2009 1:16 pm

Oh – so alt+tab to go to the other window and then start typing in it would not work then. not ready for prime time yet… perhaps we could make a fkey value trigger when a window gained focus, then it’d work better – but having to use your mouse to actually click on something would not be viable.

I think we should focus on making the modal behavior ready for primetime, because the non-modal ones sound like they won’t be good for anything except fancy floating toolbars.

It’s so cool to see this becoming a reality. I can’t wait until Gordon gets rid of line numbers like he announced at the conf in st. Louis a few years ago… that’ll be awesome!

-john

Mikhail Zheleznov · Post by **Mikhail Zheleznov** » Thu May 14, 2009 7:57 am

Issue with 4.2:

I use MyEdit to edit programs (not MyEditBR)

In MyEdit you can Configure User Tools to be able to compile your BR programs directly from MyEdit.

This works fine with 4.17

If I do this using 4.2, then the programs also work, but only in 4.2. If I try to use these programs in earlier versions of BR they error out with a 4122 Error.

The only way to correct this is to "wash" the program.

Stephen Koger · Post by **Stephen Koger** » Thu May 14, 2009 8:09 am

Mikhail
That is because 4.2 programs are stored in a new format by default. Place OPTION 60 in your wbconfig/brconfig and it will save programs in the old format and will be readable by older versions.

Steve

Stephen Koger · Post by **Stephen Koger** » Thu May 14, 2009 8:12 am

Explanation from 4.2 Release Notes New Internal BR Storage Format

BR has a new format for saving programs that allows for the expanded capacities in version 4.2. This format cannot be processed correctly with prior versions of BR. However, during development, it is desirable to be able to make changes to 4.1 programs while one is running version 4.2. So an OPTION is provided for doing this.

Think of it as a mode setting. You are saving in 4.1 format or 4.2 format at any given point.

OPTION 60 [ ON | OFF ] ! save programs in 4.1 loadable form

If an attempt is made to store 4.2 only code in 4.1 format, an error
is generated.

Post by **gordon** » Thu Jun 11, 2009 5:18 am

FYI Concerning PDF printing.. Unlike the release notes, the PDF facility requires a slash after the colon, even though no filename is given in the Name= term. This will be corrected in the next release.

e.g. This should work, but doesn't:
Name= PDF:, Printfile=work123, ...

This does work and will continue to:
Name= PDF:/, Printfile=work123, ...

Again, this is being corrected.