Here's the issue - im trying to use the URLControl in a custom module to store the URL for an image.

In the Core Module ImageModule, it uses this control.

The ImageControl Saves its settings to the Module Settings.

The URLControl.URL comes out in a format like "FileID=9" when it is of URLType = "F".
I can see it stored this way in the DB.  However if you try to set the UrlControl.Url back to this setting - it does not reset the controls to match this... it is expecting a format like "images/image.jpg" in order to make the controls match.

Somehow when the ImageModule gets its Settings("src") it comes out as "image/image.jpg". Yet I clearly saw the setting being saved as "FileID=9".

Where in the heck is this conversion to a file taking place - I cannot seem to debug through the PortalModuleBase retrieving the settings for this.

Please please help me.

ok - this is totally ridiculous...

this is the contents of the GetModuleSettings stored procedure

select SettingName,

'SettingValue' = case when Files.FileName is null then ModuleSettings.SettingValue else Files.Folder + Files.FileName end

from ModuleSettings

left outer join Files on ModuleSettings.SettingValue = 'fileid=' +

convert(varchar,Files.FileID)

where ModuleId = @ModuleId

So DNN is essentially making an exception on saving settings in a particular format to retrieve the file.

This basically makes the URLControl worthless unless you write your own conversion utility for the URL output it gives.

 

Solution:

Since I have already made a replacement URLControl (described here: http://forums.asp.net/882506/ShowPost.aspx)

I made another change to it:

in the URL Property I changed

Case "F"
If Not cboFiles.SelectedItem Is Nothing Then
If Not cboFiles.SelectedItem.Value = "" Then
Url = "FileID=" & cboFiles.SelectedItem.Value
Else
Url = ""
End If
End If

to

Case "F"
If Not cboFiles.SelectedItem Is Nothing Then
If Not cboFiles.SelectedItem.Value = "" Then
Url = cboFolders.SelectedItem.Text + "/" + cboFiles.SelectedItem.Text
Else
Url = ""
End If
End If

This makes the URL property work both ways. (At least for the "F" urltype - i haven't played with the other types, but I haven't changed them either).

Funny you brought this up, I just got done banging my head against the wall with this issue. Anyway, the answer (for me) is to fix it on the front end. Before you store the value in the database. Here is how you read the URL control and get the filename from the FileID.

Dim iconId As Integer = Integer.Parse(ctlIcon.Url.Substring(7))
Dim objFileController As New FileController
Dim objIconInfo As DotNetNuke.Services.FileSystem.FileInfo = objFileController.GetFileById(iconId, PortalId)
Dim FileName = objIconInfo.FileName

Now you store the filename in the database in the first place. Now when you go to update the icon value,
you can just set ctlIcon.Url = Filename

I am relieved that somone else found this to be an issue,  I was begining to think that maybe I was using these controls in such a wierd way that I was way off base.

 

now.. since i can't report bugs on the DNN bug tracking system - how do i know some core member see's this?

The bug tracking says to use the forums...

 

Jeff, please describe the bug as you see it.  The control is used through-out the core code without any issues that I know of.

 

Two issues.

If you are dynamically adding it to a page during a postback (with LoadControl), you can't control what sub-controls are displayed through the properties of the control. These settings are only checked if NOT Page.IsPostback.

2nd.  The Url Property isn't symmtrical in the data you must provide it.  If the control is in "F" mode (file), then if you Get the property you get a value like "FileID=8"  where if you try to set the control back using that format, it fails to properly set its subcontrol.  Conversely, you can Set the property to "images/myimage.jpg" but you will only get "FileID=8" if you try to read out of that control again.

The control seems too closely coupled with the GetModuleSettings method/stored procedure which automatically decodes the "FileID=8".  In order for any other use, you have to set up either another client call to the database through the FileInfo objcet as toddhd did, or re-write the control to make the URL property bi-directional with the same data.

My suggestion would be to put a FileID property on the control  - make the URL property get and set the same information.  The FileId would return the ID of the URL for the setting the Images control uses.  Changing the value of the FileId would potentially alter the value of URL but that would be ok.   FileId would return Null.NullInteger when it wasn't applicable.

 

 

Thanks for your feedback Jeff. Although these enhancements might make a better universal control, I don't think they can be classified as bugs.

I have to admit that I had the same thoughts when I was trying to fix an actual bug in the control saving the currently selected file for the page Url and even made a change simular to the one you are suggesting.  After checking it in it turned out that the control would no longer work in other areas that share the files because they are expecting the FileId= to be in the DB and translated in the Stored Proc.  So I ended up going back in and making the SP in question do the translation like the rest of them.

As for the postback issue when loading dynamically.  Does this also hapen if you load the control in page_init?

if you were loading it for the first time in page_init during a postback it would.  The properties that determine which subcontrols show up are not looked at ,at all, if the page is in postback.

My situation is that I have a auto-postback dropdown list of a series of templates.  Each instance of the template stores the data into an XML file.

When I choose the template I want - it determines which controls to show, anything from the URL control for choosing an image to a rich text box for including text. 

This data is then stored into the XML.  The XML is later displayed via XSLT (so it would be hard to handle the FileID=# at that time). 

The post back issue is pretty easily resolved by taking out the if statement.  I haven't done extensive testing on the effects but all the code within the If block has to do with the display of the control.

I had a similar issue with the TextEditor control where I coudln't set the Text of that control until it had been added to the page, because the Text property writes directly to the Text property of the RichTextControl which isn't added until the Page_init event (it should probably be added in a constructor, or alternatively the TextEditor should store the value and assign it to the richtextcontrol at Pre_render).

You may be right that it is not a bug, but I think it is relatively poor implementation/design for a resusable control.

Generally a property should return what you put into it.   if A=B and B= C then A= C. (or in this case if  urlControl.Url =  "images/myImage.jpg"  and "File=8" = urlControl.Url then "images/myImage.jpg" <> "File=8" and urlControl.Url <> urlControl.Url )

I also think those controls (all the ones being provided as reusable controls - ie in the /controls folder)  should be adjusted so that any display settings are resolved at Pre-render rather that in the Load event.  Even if you remove the if statement.  If someone wants to adjust the control settings during an event of a separate control (during postback) setting the property will do no good because those properties were already evaluated during Load and the Events fire after that.

A crude solution I found that worked was something like this:

string[] strArr = UrlControlObject.Url.Split('=');
nFileID = int.Parse(strArr[1].ToString());

This is in CSharp. He he :)

Two line solution for folks that are a bit squeamish about modifying all that goodness inside the DotNetNuke framework, he he.

jjmartin wrote:

Jeff, You may be right that it is not a bug, but I think it is relatively poor implementation/design for a resusable control.

I would agree with John that it's not a bug. To demonstrate why its not, think or try this...
Create a links module and add a hyperlink to a file in the portal folder. Then, go to filemanager and move the file because you decided that your directory structure is crowded and needs cleaned up. Next go back to the link module you added and click the link. Hey guess what, you didn't have to modify the link to the file. This is due solely because of the fileID.

I do see your difficulties though with the XSLT =)

Dave

If the theme is "Providers are GREAT" then this oddity is BADDDD.  Ok I'll call it an oddity, as it works as designed it may not truly be a bug...  But what if I wanted to migrate from the Core URLControl to one of my own?  This non-uniformity of storage and retrieval IS problematic!  Although I have developed a different control (that my employer may not allow me to give away to the community), this lack of easy backward compatability for everyone else might keep me from sharing anyway...

And just because the Core Team knows to watch out for this odd transformation in the GetModuleSettings method....well just how many modules are going to trip over it???  The fact that they themselves had an issue with it does not bode well for casual developers...  If one is using the URLControl, maybe you get bit once and expect it.  But what if you have a completely custom module--with no URLControl anywhere--but settings that just happen to store a string with "fileid=..."?  I'd call the implementation here "unfortunate," it not a flat out bug!

And then talk about performance...  How many millions of times an hour is this database join routine called?  And what SMALL FRACTION of those settings need this odd transformation???  So we suffer the overhead a thousand times to benefit ONE control's laziness restoring data to the UI controls???

I have been racking my brain to figure out why when I initially load the ImageModule and don't specify a width and I height when saving the settings that the image width and height are not used as it appears to suggest in the following code:

' Update settings in the database
If ctlURL.UrlType = "F" Then
   Dim objFiles As New FileController
   Dim objFile As FileInfo = objFiles.GetFile(ctlURL.Url, PortalId)
   If Not objFile Is Nothing Then
      If txtWidth.Text = "" Then
         txtWidth.Text = CType(objFile.Width, String)
      End If
      If txtHeight.Text = "" Then
         txtHeight.Text = CType(objFile.Height, String)
      End If
   End If
End If

As stated above, the ctlURL.Url is something like FileID=7. This causes the obj.GetFile(ctlURL.Url, PortalId) to always return Nothing. This is why I would classify this as a bug.

toddhd wrote:

Funny you brought this up, I just got done banging my head against the wall with this issue. Anyway, the answer (for me) is to fix it on the front end. Before you store the value in the database. Here is how you read the URL control and get the filename from the FileID. Dim iconId As Integer = Integer.Parse(ctlIcon.Url.Substring(7)) Dim objFileController As New FileController Dim objIconInfo As DotNetNuke.Services.FileSystem.FileInfo = objFileController.GetFileById(iconId, PortalId) Dim FileName = objIconInfo.FileName Now you store the filename in the database in the first place. Now when you go to update the icon value, you can just set ctlIcon.Url = Filename

This worked like a champ!  Thanks.