NT 7.12 Drop Entry Field Compile Errors

[Rob Kolanko]

I have been trying to upgrade my apps written with NT7.06 to use NT 7.12. All I can say is that upgrading from NT6 to NT7 was "a piece of cake" compared to through NT 7.11 and beyond. My first reportable error is a compile error when a NetWebForm drop entry field uses a table and has additional table records added at the end of the list.  The code that is generated for the additional records will not compile.  I add a blank table record and a zero value to allow the field to be an optional entry and be populated with blank. For an example, take the web1 example change the mailbox size entry field to a drop entry field, then select the alias table as the lookup table and add an additional row to then end of the table. All is done via NetWebForm template. I have attached my example.

My current solution is remove my additional table records from the list which allow the program to compile, but I need to be able to add the blank option back.  In many forms the  NT 7.12 application just does not work like the NT 7.06 application. It is going to take awhile to go through the code find out what has changed. For example my French version of the Jquery date picker calendar no longer returns the date. I have read that loc:option field is no longer used. I will have to investigate that. Bruce, it would be helpful to have more examples of where refactoring will have changed how old code will have to be entered.

Thanks
Rob

[attachment deleted by admin]

[DonRidley]

Hello Rob,

In reference to your Drop Down compile problems:

I going off of memory here so I may have some terms wrong...

On the tab where you put your "additional entries not found in the table" you should have two sections where you can enter these items.  One on top and one on the bottom.  I was using the one on the bottom and was getting compile errors.  I moved everything to the top and the errors went away.  Something to look at.

Don

[Bruce]

>> All I can say is that upgrading from NT6 to NT7 was "a piece of cake" compared to through NT 7.11 and beyond.

yeah, not all my fault, but I understand what you're saying. It is difficult to make some of the changes underneath without there being some knock-on effects. I apologize for the bugs though - that's not part of the plan and I try and keep those sorts of regressions to a minimum.

I've fixed the issue with the drop-list compile (I blame Don for not reporting that earlier  )

>> I have read that loc:option field is no longer used.

you've misread! (whew).
What's changed is that there's a method you can use not to set your options (cunningly called p_web.SetOption). The templates have been updated to use this method.

Using the method can make it easier for you to change an option that has already been set by the template. for example, say the template sets;

        loc:options = p_web.SetOption(loc:options,'width',400)

then you can overide that in the embed below that by just doing say

        loc:options = p_web.SetOption(loc:options,'width',600)

this is easier than adding the option to the end of the string, and a lot easier than trying to recreate the whole options string - just replacing the one setting.

That said, you can still set loc:options as a "simple string" as before - so it won't affect your existing code.

>> it would be helpful to have more examples of where refactoring will have changed how old code will have to be entered.

Bugs aside, the only code that I know will change are the calls the p_web.jQuery and p_web.Script - which I documented in the Version history (pointing at the upgrade doc.)

cheers
Bruce

[DonRidley]

I've fixed the issue with the drop-list compile (I blame Don for not reporting that earlier  )

LOL!  I should have reported it.  I was trying to take it easy on you...

Thanks for the fix!

Don

[Bruce]

Hi Robert,

>> All I can say is that upgrading from NT6 to NT7 was "a piece of cake" compared to through NT 7.11 and beyond.

without wanting to scare anyone in any way, it's probable that there are a few upcoming changes I have in mind which will cause a bit more effort in the update. For example I've been holding off on converting the "Packet" variable from a String to StringTheory for a while now. There are some big advantages to moving it to StringTheory, but that will also likely affect embed code the most, so I'm waiting for the right time - and indeed I'll probably spread the load a bit over multiple updates. There are a few other things I still want to do as well.

Obviously I want to cause as little pain as possible, and so refactoring of any kind takes that into account. Clearly one option would be to "leave it alone", but that prevents us from doing some _really_ neat things both in the short term, and the long term.

For example the 7.13 build has a new feature called "Immediate Locators" which necessitated much refactoring of the generated browse code (mostly by breaking the existing GenerateBrowse routine into a number of smaller routines.) This should have no effect on existing code (although it is possible that it can break some existing embed code, especially if you use variables local to a routine.) On the other hand the feature is pretty cool (I think) - I'll be showing that on the Friday Webinar (www.clarionlive.com).

There are also a lot of other improvements going on "under the hood" - getting the browse-in-browse support right is a big deal (not there yet, but making progress) as well as (of course) the goal of "Form Next Form" editing.

One thing that is working nicely in 7.13 though, and you may not even notice, is that events are now flowing from children to parents, as well as from parents to children. So, for example, editing a line item on a child browse automatically updates the total on the parent browse, and so on. I want to take this idea a bit further in a later build, but for "immediate" relationships it seems better now.

In short - I apologize for the pain during the changes of course, but I think the places we're going is very exciting, and some of the things I hope to show at the devcon training are, frankly, jaw-dropping even to me. I just hope I get them done in time! In the end I think the short-term pain will be long forgotten as we enjoy the long-term benefits.

cheers
Bruce

[Rob Kolanko]

Hi Bruce,
Sorry, I was a little frustrated when I wrote this post because I see a much bigger task than I was expecting to do this upgrade. I still have forms that are not functioning the same as before. When I have to reopen projects that considered complete because I want to move forward with new projects with latest updates is hard to explain to the powers that be.  One reason I upgraded is that I need to get the “Save and Next” form to form process working and you had mentioned that this would be easier with changes in version 7.11. Thus a “not-so-exciting” feature I would like to see would be the “Save and Next” with a return to the browse at the last modified record when  a regular “Save” is done.  My View01 example does not work any better with NT 7.12. So any new ideas on how to set the value/session variables to get this working now would be greatly appreciated.  I will be watching this Friday’s webinar  and I look forward to your comments on the training at Devcon.

Regards,
Rob

[Bruce]

Hi Robert,

no worries mate - the "Save and Next" is on the list, but not quite there yet.

cheers
Bruce

[kevin plummer]

Hi Rob,

you should consider VM Workstation. It's the easiest way to try new NT versions and keep archived versions without having to roll back if you have problems. It's been a lifesaver for me.

Cheers,

Kev

[DonRidley]

Good Advice Kevin!

I actual keep a copy of every build I do. 

I can roll back to a previous NT build pretty easy.

I also extensively make use of VM's.  Would be hard to live without them.

Don

[terryd]

Another option is MACS (see Bruce's ClarionLive webinar 140). I use it for each version of Nettalk going back to one or 2 NT4 applications still live. To test I just copy the code to the folder I keep for the latest version, test as much as possible and if no problem continue from there. If there is a problem I still have my original version untouched.

[Rob Kolanko]

Yes, I also have means where I have multiple versions of Nettalk, so I can still maintain my current products. It is just that a new product that I am working on will be sold with our current products, thus the current products will need to be upgraded to at the same NT version.
Rob