After just about getting the hang of HTML Composer in 7.6.8, I'm poking around in 7.6.11 and I cannot get the simplest form to work.

I created a fex that reads the CAR file, with one parameter COUNTRY.

I created an HTML page and added a form. The submit button points to the fex. The parameter was added as a drop-down list-box. I then configure this list-box to be dynamic, with an embedded procedure reading the car master, with CAR.ORIGIN.COUNTRY as the value and disply fields.

I run the HTML form - nothing in the COUNTRY drop-down list box, not even the ALL option.

I am confused. The Parameters tab has moved from the right side of Dev Studio to the left side, and there's icons that represent parameters and controls. This is new. "combobox1" is connected to parameter "COUNTRY" via an arrow. So, what's wrong?

Is your server also running 7.6.11? In my experience it won't work if that's still 7.6.8. I think a 7.6.8 server is missing the "something" (1) that accepts the new type of request (2), or it can't parse the new and extended xml message being send to it.

We migrated between those very same versions, it took us a while to get the hang of all the changes.
That said, I find the new approach easier to use, but I haven't used the 7.6.8 approach much. It takes a bit to get the hang of, but now you have a choice between two approaches where you didn't before. Choice is good

As a piece of advice, don't blindly change every form that uses !IBI.FIL into one that takes advantage of the new embedded procedures. Both approaches have advantages over each other, it depends on the circumstances which is best.
For example, if you're going to perform the same query for several form input elements, then embedded procedures aren't as efficient as !IBI.FIL substitutions. Usually the performance is adequate enough that it doesn't matter, but in those cases it isn't...


Ad. 1: Does it use SOAP?
Ad. 2: It's AJAX - asynchronous javascript and xml, but it it's used synchronously. I suspect this is because the folks implementing it chose to be a bit conventional to reduce the risk that some browsers wouldn't pick it up very well. Of course, one particular browser is sufficiently non-complient to any standards that that choice doesn't matter... If you use anything recent you should be ok (FF3+, IE7+, etc).

Wep5622, thanks very much for your tips.

These two environments are different - I'm using Dev Studio 7.6.8 on server 7.6.8 and DS 7.6.11 on server 7.6.11 so I don't know why I have the problem. I switched to an external procedure with no luck...

Unfortunately, choice is NOT good , because, as far as I know, opening and saving an HTML file in 7.6.11 renders it incapable of being opened in the GUI of a prior release.

Is ibisamp in the path?

Yes, I can run the external procedure on its own - it generates the XML file.

This is all in MRE, if that makes a difference.

quote:

as far as I know, opening and saving an HTML file in 7.6.11 renders it incapable of being opened in the GUI of a prior release.

You are not crazy, this is true.

- ABT

P.S. Let me know when you discover the Calendar Control bug. That's a fun one...

I have one Calendar Control bug in v7.6.8: I have turned NLS on and login to B.I. Dashboard selecting French as language. I have a Calendar Control that shows English month names even if French was selected - I made sure that the language variable IBIWF_language value is 'fr' so it seems there is a bug here. I guess I haven't found the one you did!

I don't suppose you mean the bug where the calendar icon disappears from the control after you deploy the project? Or do you mean the bug where different methods of entering the date (by typing versus by selecting it from the calendar popup widget) results in differently formatted input dates in your fex? Or yet another one?

We have code like this in our fexes to work around some of the problems:

-SET &DATEFROM = IF &DATEFROM LIKE '__/__/____'
-	THEN EDIT(&DATEFROM ,'$$$$$$9999')||EDIT(&DATEFROM,'$$$99')||EDIT(&DATEFROM,'99')
-	ELSE EDIT(&DATEFROM ,'$$$$9999')||EDIT(&DATEFROM,'$$99')||EDIT(&DATEFROM,'99');

I just don't understand how people successfully develop using the HTML Composer when you have to code to compensate for the bugs - why bother using the GUI at all?

Aren't we glad to have people like you always at the front line, tirelessly beating the bugs out of our teritories...but,
They're our best friends! They are royal and accountable no matter what we do, we upgrade, upgrade, buy bigger powerful hw, change platforms, change companies, move to another continent, and they are still right beside us. In fact, we are the benefitiaries of their existence - job security!
Have a happy foolish day

Hua

quote:

Originally posted by Francis Mariani:
I just don't understand how people successfully develop using the HTML Composer when you have to code to compensate for the bugs - why bother using the GUI at all?

I share your frustration Francis! Unfortunately I do not have the skill set to develop launch pages in the text editor. I sure do spend a lot of time fixing things that the GUI breaks. There are times when the simple act of opening a page in the GUI causes stuff to break. I've even resorted to making a copy of my page, opening the copy in the composer, making the changes I want, and then using WinMerge to compare the new file to the original so I can see where things were changed that I didn't want changed.

I sure wish there was a way I could build my pages in a 'real' HTML editor and then add the WebFOCUS bits after the fact but I haven't found a way to make that work. Importing existing HTML code into the page doesn't work very well.

With regard to your 7.6.11 issues - we abandoned 7.6.11 all together and are going to skip over it in our upgrade path. It just broke too many things and didn't offer enough by way of new functionality to justify the time it would take to make the necessary repairs.

Regards,

Dan

quote:

I've even resorted to making a copy of my page, opening the copy in the composer, making the changes I want, and then using WinMerge to compare the new file to the original so I can see where things were changed that I didn't want changed.

- Exactly what I do.

quote:

we abandoned 7.6.11 all together and are going to skip over it in our upgrade path. It just broke too many things and didn't offer enough by way of new functionality to justify the time it would take to make the necessary repairs.

- Ouch! This is the version we're upgrading to, there's now way I can sell the powers-that-be to upgrade to 7.7.02 - sounds too scary to them.