My primary client is interested in upgrading to the "latest" version of BR. They are currently using 4.17 WITHOUT NWP. They want to use NWP so we can print to some of their braindead printers as well as to solve some other driver issues. They also want to "become current" (their words). Their board of directors is sort of all or nothing and if they approve the "get current" scheme, then it will be awhile before we can do anymore BR upgrading. I don't want to miss my chance, but I don't want to saddle them with loads of problems on a deployed system either.
I have some printing issues to resolve before we go to NWP, but I don't see this as a problem.
I need to do some testing because they are not running in GUI mode at the moment. I can switch in and out of that as needed until I have it all up and running. In the meantime, I'll just use a non-proportional font to run my old programs.
To go to 4.18, I have to modify my libraries because I will get hit by the changes in library scope.
Should I just go all the way to 4.2 at this time? This is a single custom client, not a vertical market application with multiple companies using it. They are running 13 users on a Windows 2003 Server platform with the regular BR version, NOT client-server. All workstations are running Windows XP. I don't intend to implement many 4.2 features right away since we are quite behind on GUI features in the first place.
I'm trying to decide if 4.2 is stable enough NOW to go there for this client, or should I wait? Is there a rough (REALISTIC) ETA on 4.2's official release?
In my experience, 4.2 is very compatible with 4.18 - in other words, my 4.18 programs run just fine under 4.2 without changes to wbconfig.sys or any of my programs.
Now, I'm not doing every single thing BR handles, so I cannot offer a guarantee that it will work for everything you might be doing. But I do try to make sure my software takes advantage of as many BR features as useful/possible so that I can use it as a decent test environment for new BR releases.
I would say in my experience, the 4.18 features all work fine under 4.2. However a few of the 4.2 only features still need a bit of polishing in 4.2 before they are totally done. If you are not planning on implementing any 4.2-only features in your programs yet, then you probably don't have anything to worry about in going to 4.2.
If you have your programs running under 4.18 (using gui-off or whatever), then they should run under 4.2 as well. But its an easy matter to drop in 4.2 and test it before you go to the client with your recommendation.
Another thing to consider is that you can always license for 4.2 and
install a prior version if you are unsure about the current release.
This would allow you to put them on a stable 4,18 release right now and
allow for the use of the new 4.2 features in the future without a second
BR upgrade cost.
I haven't implemented 4.18 features yet EITHER, but perhaps I'll go that route: license the client for 4.2, USE 4.18 feature set and then I'll be ready for both worlds. Thanks!
-- Susan
Last edited by Susan Smith on Thu Jun 11, 2009 8:55 am, edited 1 time in total.
All our current clients are 4.2 licensed, we did that in mass two years ago. But we are just now moving from 4.17 to 4.18 in the field as far as running version.
I recently switched to 4.2 in all my web apps and it works well. Seems a little faster, too. Especially once I implemented the 4.2 optimizations to my programs. Actually, The Bridge detects 4.2 and uses the optimizations automatically. : )
I should note that my programs use few of the newer BR features. Just the web stuff.
I’ve been running 4.2 in the office now for three months and it works great. I have not implemented any PEM’s but the rest works great. I would not hesitate to move forward. In doing so you can always set OPTION 60 ON and OPTION 56 so that if anything happens, that I don’t think will, you could drop back to 4.18 in an instant by changing the executable.
When running BR 4.2 --
When you turn on the OPTION to save programs in 4.18- format, is the only thing that you lose (of the 4.2 features) the longer line length in your programs? Or are there other drawbacks to using this OPTION?
-- Susan
P.S. I wanted to thank you for your excellent tutorials of the past few conferences regarding moving up to GUI and to 4.2. I have all of my past conference books open, bookmarked to various "George" writings and I am finding them very helpful! Your thoroughness is much appreciated, especially when a lot of time has gone by and I've forgotten much of the material (middle age disease you know...)
Last edited by Susan Smith on Thu Jun 11, 2009 8:56 am, edited 1 time in total.
The WOW factor of parent=none windows is so great that it overrides any other factor that you may think about in not moving to 4.2. It is something that your clients will really notice ( or perhaps it would be better said that they will notice the lack of moveable windows if you stay at 4.18 ) and puts you in the league with other up-to date languages from a user’s perspective. Add to that the ease of creating PDF files and you have a “no-brainer”.
I agree with you about the wow factor of 4.2 child windows. But the problem is that the 4.2 child windows Take the Focus of the BR program. Therefore, if the user tries to click on the rest of your program its either DEAD, or worse, it does something random to the child window that actually has the focus.
4.2 Child Windows are MODAL - that is, they are the only thing active on the screen when they are open, and the parent window is DEAD. Unfortunately, they DO NOT act modal, which is confusing to the user. That means, they can easily accidentally click somewhere and the child window will POP behind the parent window and then they will have no idea why the program just stopped responding. Just check out your example programs on the flash drives, and you'll see what I mean.
You are your only end user, so its no big deal to you. But my users would think the program was broken if I attempted to use 4.2 PARENT=NONE windows the way they are now. Unfortunately, for me, until this is fixed, PARENT=NONE is an unusable feature.
I disagree about the focus. The early releases of 4.2 did have the problem with focus that you refer to and you can force an active window into the background behind an inactive window. BUT when you initiate any action on a BR screen the active window pops to the front.
Also, yes, I am my own best customer, but I do have two women who work for me that use the software constantly and I have a significant manufacturing company client that runs their entire business using my software so I am able to see how others react to the software and window behavior. As currently configured I have no problem setting a user free with no-parent windows. I also feel constrained anytime that I have to go back to the old window structure of 4.18.
Parent=none is not meant to be used for a child window. The syntax itself implies this. The fact that an independent window can be masked by another window is simply the way Windows works and I don't think anyone has a problem with it.
AND I tested true child windows under 4.2 (parent=something) and they don't disappear behind the main window when the main window is clicked on. While they are processed modal (one window at a time) the main window can be active while a child window exists. This is because child windows are used for different purposes that are not modal.
Now without FORCE_VISIBILITY fields below child windows are masked by the children but this is normal Windows behavior as well.
i have attached a sample program for demonstration.
Gordon
Can you give us an example of how if I have two parent=none windows open, each containing a 2D control, how I can programmatically capture both keyboard or mouse input on either window in the 2D Controls? Would the NEXT Feature assist with this?
Parent=none gives you a window that is active, making the main program no longer active. Therefore the Parent=NONE window is not independent.
Clicking on the main BR window will cause the Parent=NONE window to disappear, and the user will think they are back on the main window again, doing whatever they were doing before.
Then when they try to type, BR puts their characters in the Parent=NONE window (which is now behind the main window). Now, they call me and ask me why my program is frozen.
Then I try to explain to them that its not frozen, that they are just "IN" the Parent=NONE window.
Then they tell me, "I'm not in the Parent=NONE window?!? What are you even talking about? I don't see any other window!!!"
Then I tell them, "Look at the taskbar". See that other window there? You were typing in that other window.
Then they say, "oh, is that where my cursor is? Why would it be back there?"
Because of this, I am unable to actually USE parent=none windows in any of my programs.
I'd love to use them. Its like a steak dangling tantalizingly in front of me but I can't actually reach out and taste it.