02:43:21 PM
3GK0VK1BU
Note also that I distribute my wcsx / asp-style page to production since I run into a problem (I can't recall what) if I do not. Could this present a factor contributing to the no display of calendar.gif I wonder.
You'd know much better than I, but just FYI in case you still want to try and duplicate this. After all, you have a much nicer environment in which to work (HI).
TMI:::: I am in FL now, but I am from San Diego and am very much missing the dryer climate. I've been told HI is even better. Maybe one day I'll see (you lucky "so and so"). <s>
Thanks again for all the clues -b (clue-less).
The script tags below should work although those are DUPLICATES. That's why they were INSIDE of the ww:wwWebLiteral box with visibility set to false.
The date picker control will automatically load the scripts required from the same location. Those script tags are there only for Intellisense to work in Visual Studio. If you leave those script tags in the scripts will get loaded twice - this should still work, but put extra load on your network.
+++ Rick ---
Culprit found. Apparently, a <script> tag directly in my asp style page was causing the wrong version of the jquery libs to load.
The problem was resolved by commenting the script tags in below snippet. Does this make sense? Care to elaborate before I post this solution on messageboard, or ? (I am going ahead and posting so I don't forget). I suspect these script src elements are left over from the first go at WC ... live and learn.
<head> <title> <%= this.page.cPageTitle %></title> <link href="westwind.css" rel="stylesheet" type="text/css" /> <ww:wwWebLiteral ID="WwWebLiteral1" runat="server" Visible="false"> </ww:wwWebLiteral> <script src="~/scripts/jquery.js" type="text/javascript"></script> <script src="~/scripts/ww.jquery.js" type="text/javascript"></script> </head>
I ran updateversion.prg, but I will confirm the scripts folder is updated next. I am putting together a sample set for you which I will send by email attach.
Did you upgrade the scripts folder for your site as well? The logic changed but the scripts need to be updated as well.
I'm using the DatePicker in several apps so I'm confident that it works. I would like to see an example that fails please if you could. Something reproducible so I can test it would be useful...
+++ Rick ---
Hi Rick,
Maybe I forgot to chant, but all I am doing is upgrading from 5.50 - to 5.60. This is a page that has been working great with the date pickers for about a year now. The date pickers allow users to select a date window for which to view data they've processed in the recent past and has always worked well. Both date pickers (floor dand ceiling) are set to autopostback.
The final "view code" output in the page shows the correct LOGICAL path to calendar.gif (in <sitefolder>\images\calendar.gif where <sitefolder> is my logical folder).
All other images on the same page are working with just Images/<imagefile> as the path.
Note nothing else has changed (that comes to mind) other than the WC framework and the necessary changes on my end as outlined in "Whats New". It almost seems like the image button's set invisible or may not be getting fully initialized?
FYI, I am using VWD 2008 too. I'd be happy to send you the "asp" file.
Possibly. If script fails to run the date picker shouldn't show up at all though - you would just get the textboxes. But not a broken image.
If there are two references in the page one will overwrite the other so that shouldn't be a problem other than the wasted bandwidth.
What are you doing exactly?
+++ Rick ---
I should also divulge that IE's reporting the following.
"Object doesn't support this property or method"
re:
jQuery(document).ready( function() { jQuery('#txtBeg').datepicker({showButtonPanel:true,changeMonth:true,changeYear:true,showOn: 'button', buttonImageOnly: true, buttonImage: '/IPALTestBED/images/calendar.gif', buttonText: 'Select date',beforeShow: function(input) { $('#ui-datepicker-div').maxZIndex(); },showButtonPanel: true,dateFormat: 'mm/dd/yy'}).attachDatepickerInputKeys();
Again, in my page that is displaying the calendar graphic correctly, there's only one copy of the js function: attachDatepickerInputKeys. In the page where the calendar graphic is not displayed (and has the above error), there are TWO copies of the js function attachDatepickerInputKeys. could this be the culprit?
Hi Rick,
I think I may have a problem resulting from the new path conversion. The calendar.gif is not displaying on one of my two pages which use the date picker control. Previously, I have been able to address this particular issue by making sure SET EXACT was OFF (since ResolveURL relies on this too). However, this one's got me baffled.
I've looked at everything I can think to; even assuring SET EXACT is off when ResolveURL is called and the correct <i>logical</i> Images/folder path is returned by ResolveURL and I verified the image file does exist. It was working at version 5.53. After upgrading to 5.60 it is not. No other changes have occured. In fact, it is working on one page and not on another. I have two date-picker controls on each page (working and not).
The only difference between the rendered page code that I can see is the script resulting from calling AttachDatePickerInputKeys is being generated twice in the resulting page ouput for the page that is not displaying calendar.gif. Could this be the culprit?
I'm about to push out an update to Web Connection starting with a Beta of 5.51 in the next couple of days or so.
This is mostly a maintenance release. Here's all that's new:
For the most part these are maintenance items, however there are a couple of potentially disrupting items on the list.
Retiring wwIPStuff Class
The wwIPStuff class has been something that's been bugging me for some time - the class provides a bunch of different functionality but it's all scrunched together into a single class and a lot of folks continue to use this class instead of the respective self contained clases of wwHttp and as of 5.50 wwSmtp which are feature and API compatible. The class also hosts a number of small 1 method IP based utility methods. The worst part about it though is that the class interface of this class is confusing because it serves a host of different tasks.
So... I'm finally pulling the plug on the class itself in this update by isolating out all the pieces that are in it into separate classes (some of which has already happened some time ago). Here's where the functionality goes:
Http features - wwHttp class (wwHttp.prg - been that way for a long time)
Smtp features - wwSmpt class (wwSmtp.prg with nMailMode =2 - exists since 5.50)
wwFtp Class - wwFtp.prg class (new for 5.51)
wwSocket Class - wwSocket.prg class (new for 5.51)
EncodeDbf
DecodeDbf
ZipFiles
UnzipFiles - all to wwUtils.prg as standalone functions
InternetDial
InternetHangup
RasDial
RasHangup
GetDomainFromIp
GetIpFromDomain
Ping - moved to wwAPI as standalone functions
The idea is to make these components more modular so you don't have to include all of the functionality if you only need one or the other features. With this wwIPStuff.vcx becomes obsolete.
wwipstuff.vcx will continue to ship for backwards compatibility but it will be removed from the default loading list of components.
New ~/ Path Translation
Web Connection now will automatically transform root-relative paths (~/) in attributes into fully qualified root-relative virtual paths. So something like <img src="/wwThreads/images/image.gif" /> will automatically translate into <img src= "/wconnect/images/image.gif" />. This is quite useful for creating paths that are completely location independent - these paths are effective application relative rather the fragile path relative syntax of ./ or ../ which can easily change based on the location of the file.
There's a lot more info on this in this blog post:
http://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=807
This should really have zero effect on applications, except you get the new functionality. However, I'm curious to hear if this causes any problems in perf or other interference in your applications in any way.
As always I'm interested in any feedback you might have of the new features and implementation. I'm especially interested in some feedback on the wwIPStuff changes. The reasoning here is that moving forward with Web Connection and the toolset I want to slowly start to cleanup various APIs for better consistency. Some of this stuff is really showing its age in terms of design vision <s> - apparently I wasn't a big fan of specialization in the distant past.
Anyway love to hear any feedback you might have,
+++ Rick ---
