This post and any that follow in this thread are aimed at no one in particular.
The thing is I keep 'discovering' things that aren't documented or are badly documented and I thought that it might be a good idea to write them down somewhere.
The thing is I keep 'discovering' things that aren't documented or are badly documented and I thought that it might be a good idea to write them down somewhere.
14 Answers, 1 is accepted
0
Dan
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2007, 09:28 AM
Testing for Zero rows (client-side).
Simple, huh?
Nope. You will always get at least one row, or you will if you have any NoRecords template (including the default one) defined.
Your test should be...
You could argue that you don't need the first test, but the 2nd will fail if you ever disable the NoRecords template (I think).
--
Stuart
Simple, huh?
| function GridCreated() { |
| if (this.MasterTableView.Rows.length == 0) { |
| // Do your no rows action |
| } else { |
| // Do your rows available action |
| } |
| } |
Your test should be...
| if (this.MasterTableView.Rows.length == 0 || this.MasterTableView.Rows[0].ItemType == "NoRecordsItem ") |
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2007, 09:49 AM
Tying Client Click event to toolbar after AjaxRequest.
There are a couple of forum posts and a KB article about this. The later is here. So, what can I add to that? You may well ask.
Being clever, and not wanting to have too much JavaScript in my page (if it's in its own .js file it's chached, which is what I wanted) I thought to create a number of global JavaScript variables. So my .aspx page included this ...
The thing is, my toolbar click actions weren't firing after an AjaxRequest. A bit of a chat with telerik support suggested that everything looked right, but then the guy on support got someone else to cast a fresh set of eyes over the code.
Apparently, <quote>the scope for the toolbar instance does not extent to the event handler</quote>. In practice this means I had to modify the code to read...
Sneeky!
--
Stuart
There are a couple of forum posts and a KB article about this. The later is here. So, what can I add to that? You may well ask.
Being clever, and not wanting to have too much JavaScript in my page (if it's in its own .js file it's chached, which is what I wanted) I thought to create a number of global JavaScript variables. So my .aspx page included this ...
| var gToolbar = <%= Toolbar.ClientID %>; |
| gToolbar.attachEvent("OnClientClick", "toolbar_OnClick"); |
| function OnResponseEndHandler(sender, arguments) { |
| gToolbar.attachEvent("OnClientClick","toolbar_OnClick"); |
| } |
The thing is, my toolbar click actions weren't firing after an AjaxRequest. A bit of a chat with telerik support suggested that everything looked right, but then the guy on support got someone else to cast a fresh set of eyes over the code.
Apparently, <quote>the scope for the toolbar instance does not extent to the event handler</quote>. In practice this means I had to modify the code to read...
| function OnResponseEndHandler(sender, arguments) { |
| <%= Toolbar.ClientID %>.attachEvent("OnClientClick","toolbar_OnClick"); |
| } |
Sneeky!
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2007, 10:12 AM
The toolbar separators that wouldn't die.
I have a toolbar with a number of functional groups of buttons separated with separators. The toolbar also contains 2 hidden buttons; OK and Cancel.
When an action requires a confirmation action from the user, I hide all of the toolbar items then show OK and Cancel.
Fine, works a treat, unless the use does something that causes an AjaxRequest whilst these buttons are active (or rather everything else is hidden). When the toolbar redraws the separators are back!
Support tell me that it is a known problem and the only option is to remove the buttons from the collection (instead of hiding them) and then re-add them when I need 'em back.
Not elegant, but it works.
--
Stuart
I have a toolbar with a number of functional groups of buttons separated with separators. The toolbar also contains 2 hidden buttons; OK and Cancel.
When an action requires a confirmation action from the user, I hide all of the toolbar items then show OK and Cancel.
Fine, works a treat, unless the use does something that causes an AjaxRequest whilst these buttons are active (or rather everything else is hidden). When the toolbar redraws the separators are back!
Support tell me that it is a known problem and the only option is to remove the buttons from the collection (instead of hiding them) and then re-add them when I need 'em back.
Not elegant, but it works.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2007, 10:24 AM
Treeviews, checkboxes and Ajax.
There is a documentation article here that shows you how to arrange things so that your user can only check one box in a treeview.
I set it up and it worked just fine, until (can you guess?) I initiated an AjaxRequest. Thereafter I got a JavaScript error when clicking on a checkbox. The error - Object Expected - was tracked to the call to node.UnCheck(); I've no idea why but changing the suggested function to read ...
Works.
Go figure.
There is a documentation article here that shows you how to arrange things so that your user can only check one box in a treeview.
I set it up and it worked just fine, until (can you guess?) I initiated an AjaxRequest. Thereafter I got a JavaScript error when clicking on a checkbox. The error - Object Expected - was tracked to the call to node.UnCheck(); I've no idea why but changing the suggested function to read ...
| var oldNode; |
| function FolderCheck(node) { |
| if(oldNode != null) { |
| try { |
| oldNode.UnCheck(); |
| } |
| catch (e) { |
| // do nothing |
| } |
| } |
| node.Check(); |
| oldNode = node; |
| } |
Go figure.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 13 Feb 2007, 04:41 PM
Grid Edit Forms - Styling
For some reason, when the guys at telerik did all the work on skinning, they completely forgot about the default edit form.
What this means in practice is that you have to write your own classes and add them to your CSS file. You also have to make sure that the names of those calsses are correctly assigned to the various properties of the grid. For most of us these are properties of RadGrid.MasterTableView.EditFormSettings. If you're using hierarchical tables you'll need to set these values for each table (or are they inherited from MasterTableView??).
Another point to note is because of the above if you change skins you need to copy your new classes in to the new skin's CSS file. Alternatively, you can put your EditForm's classes in a different file and they will 'follow' you around when you change skin. This is because, unlike the skin's classes, the EditForms classes aren't assumed, by the grid, to end in '_<skinname>'.
Anyhow, that's where you need to be playing. I guess the sensible thing to do if you have a complex form is to create a template and style that. In my case only 2 of my 8 columns are editable so I'm using the default form (with a custom editor for one of the columns).
One other point. My boss has an almost pathalogical dislike of the telerik standard of putting the 'edit', 'update' and 'cancel' buttons on the data row. Now, whilst this prolly says more about his state of mind than anything else, as the programmer it became my problem to 'fix'.
I'll look at creating any using the action buttons later, but you need to get rid of the default controls. Now we know about EditFormSettings this is easy; just set EditFormSettings.EditColumn.Display = false and they're gone.
--
Stuart
For some reason, when the guys at telerik did all the work on skinning, they completely forgot about the default edit form.
What this means in practice is that you have to write your own classes and add them to your CSS file. You also have to make sure that the names of those calsses are correctly assigned to the various properties of the grid. For most of us these are properties of RadGrid.MasterTableView.EditFormSettings. If you're using hierarchical tables you'll need to set these values for each table (or are they inherited from MasterTableView??).
Another point to note is because of the above if you change skins you need to copy your new classes in to the new skin's CSS file. Alternatively, you can put your EditForm's classes in a different file and they will 'follow' you around when you change skin. This is because, unlike the skin's classes, the EditForms classes aren't assumed, by the grid, to end in '_<skinname>'.
Anyhow, that's where you need to be playing. I guess the sensible thing to do if you have a complex form is to create a template and style that. In my case only 2 of my 8 columns are editable so I'm using the default form (with a custom editor for one of the columns).
One other point. My boss has an almost pathalogical dislike of the telerik standard of putting the 'edit', 'update' and 'cancel' buttons on the data row. Now, whilst this prolly says more about his state of mind than anything else, as the programmer it became my problem to 'fix'.
I'll look at creating any using the action buttons later, but you need to get rid of the default controls. Now we know about EditFormSettings this is easy; just set EditFormSettings.EditColumn.Display = false and they're gone.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 14 Feb 2007, 08:28 AM
Putting all of you action controls in one basket.
I mentioned yesterday that my boss doesn't like to see the 'Edit' link button on the grid when it's designed for editing. He're almost as keen to see the 'Update' and 'Cancel' buttons gone too.
Wilthout giving away too many clues to my age 8-) I can say that I started working in programming with database engines like Informix, whose forms had all of the controls along the top row of the (80 x 25) screen. These controls (read: text labels) changed to suit the context of the task at hand.
Following on from that, if there were a number of UI elements on the screen, where an action isn't caused by a direct and necessary interaction with the control, the feeling here (in house, I mean) is that the controls should be centralized. This is where r.a.d.Toolbar comes in.
First let me say I'm not talking about never interacting directly with (say) the grid. If the only control on the page then use the CommandItem, but if there are other controls (in the case of this project Upload and Treeview) then we try and make it so that the user only has to go to one place on the form to find the control to initiate the action s/he wants. Obviously, if I want to change node on the treeview, I click the node that I want or to select a row in the grid, I'll click on the grid.Similrly the 'default' action on the grid is initiated by double clicking.
In this project a secondary function of the grid it to allow the user to edit some elements of the document details shown. To do this I added a toolbar button that puts the selected row in the grid in edit mode.
In keeping with the idea of keeping the controls centralized, once we've gone in to edit mode, I hide all of the buttons in the toolbar except for 2 (previously hidden) buttons with CommandNames of "EditOK" and "EditCancel". Now it won't take the brains of an archbishop to figure out what they do.
If the user selected the "EditOK" button I have to call the code that validates the data, updates my datasource and takes the row out of edit mode.
Because of the way the telerik code is written you don't seem to be limited to just doing it their way, so I can get at the data (both the old values and the new) validate and cacnel the update if it's wrong etc.
At the moment I'm struggling to make telerik's sample code for extracting updated values from the user form (found in this article) to work, but I'm not to far off I think.
OK. Maybe I'm rambling now so I'll shut up. I guess I've not really added to the overal sum of human knowledge with this post, but I wanted to show that you don't just have to do things the default way; if your 'house' style requires a different approach, then those clever boys and girls at telerik have prolly left you enough wiggle room to do it your way.
--
Stuart
I mentioned yesterday that my boss doesn't like to see the 'Edit' link button on the grid when it's designed for editing. He're almost as keen to see the 'Update' and 'Cancel' buttons gone too.
Wilthout giving away too many clues to my age 8-) I can say that I started working in programming with database engines like Informix, whose forms had all of the controls along the top row of the (80 x 25) screen. These controls (read: text labels) changed to suit the context of the task at hand.
Following on from that, if there were a number of UI elements on the screen, where an action isn't caused by a direct and necessary interaction with the control, the feeling here (in house, I mean) is that the controls should be centralized. This is where r.a.d.Toolbar comes in.
First let me say I'm not talking about never interacting directly with (say) the grid. If the only control on the page then use the CommandItem, but if there are other controls (in the case of this project Upload and Treeview) then we try and make it so that the user only has to go to one place on the form to find the control to initiate the action s/he wants. Obviously, if I want to change node on the treeview, I click the node that I want or to select a row in the grid, I'll click on the grid.Similrly the 'default' action on the grid is initiated by double clicking.
In this project a secondary function of the grid it to allow the user to edit some elements of the document details shown. To do this I added a toolbar button that puts the selected row in the grid in edit mode.
In keeping with the idea of keeping the controls centralized, once we've gone in to edit mode, I hide all of the buttons in the toolbar except for 2 (previously hidden) buttons with CommandNames of "EditOK" and "EditCancel". Now it won't take the brains of an archbishop to figure out what they do.
If the user selected the "EditOK" button I have to call the code that validates the data, updates my datasource and takes the row out of edit mode.
Because of the way the telerik code is written you don't seem to be limited to just doing it their way, so I can get at the data (both the old values and the new) validate and cacnel the update if it's wrong etc.
At the moment I'm struggling to make telerik's sample code for extracting updated values from the user form (found in this article) to work, but I'm not to far off I think.
OK. Maybe I'm rambling now so I'll shut up. I guess I've not really added to the overal sum of human knowledge with this post, but I wanted to show that you don't just have to do things the default way; if your 'house' style requires a different approach, then those clever boys and girls at telerik have prolly left you enough wiggle room to do it your way.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 16 Feb 2007, 05:29 PM
More on centralizing controls and why r.a.d.Upload no longer holds any fear.
OK. We've all seen the Upload example on the demo pages here at telerik central. What's the one thing that they all seem to have in common? No? They all have a submit button but not one to Cancel the process.
In a number of places we are told that any postback will, however it is caused, cause any selected files to be uploaded. This is, apparently, a function of the underlying bits of Microsoft code.
Later articles in the forums and KB tell us that we can do some client-side trickery to clear the file input selections before a postback.
All of the examples show use controls like ASP buttons or HTML inputs to manage this.
Of course, muggins here is stuck with trying to get a toolbar button to do it. This, it appears brings its own set of problems because my toolbar is managed by a r.a.d.AjaxManager and Upload won't work with Ajax.
I had the idea of calling a bit of JS from my toolbar button that would call a postback rather than call the AjaxRequest but couldn't get it to fly properly.
Then Valeri Hristov wandered in to this thread. And all of a sudden things started to make sense.
The trick can bee seen in its glorious majesty by looking at the thread pointed to above, but in summary, add a linkbutton or some such control to the page. This control's 'click' event is where your post-upload code is going to go. You can hide this control in a DIV with style="display:none;".
Add 2 JS functions to the page. The first one just calls __doPostBack("<%= MyLinkButton.ClientID%>", ""); Let's call this function doUpload. The 2nd one clears all of the file inputs before calling the same __doPostBack call. We'll call this on doNotUpload.
Create 2 toolbar buttons and manually edit the ASP code to include onclick="doUpload();" for the one and onclick="doNotUpload();" for the 2nd.
Add a function in your code-behind to process the LinkButton's Click event and you're done!
Note that your server-side click event needs to handle the fact that sometimes (ie when your 'Cancel' toolbar button is pressed) there are no files in your UploadedFiles collection.
You might wonder why I bother posting back if there are no files to upload. That's simple; the Upload controls are not on a separate page, but are part of my main page so I want to hide them when the user clicks on cancel.
--
Stuart
OK. We've all seen the Upload example on the demo pages here at telerik central. What's the one thing that they all seem to have in common? No? They all have a submit button but not one to Cancel the process.
In a number of places we are told that any postback will, however it is caused, cause any selected files to be uploaded. This is, apparently, a function of the underlying bits of Microsoft code.
Later articles in the forums and KB tell us that we can do some client-side trickery to clear the file input selections before a postback.
All of the examples show use controls like ASP buttons or HTML inputs to manage this.
Of course, muggins here is stuck with trying to get a toolbar button to do it. This, it appears brings its own set of problems because my toolbar is managed by a r.a.d.AjaxManager and Upload won't work with Ajax.
I had the idea of calling a bit of JS from my toolbar button that would call a postback rather than call the AjaxRequest but couldn't get it to fly properly.
Then Valeri Hristov wandered in to this thread. And all of a sudden things started to make sense.
The trick can bee seen in its glorious majesty by looking at the thread pointed to above, but in summary, add a linkbutton or some such control to the page. This control's 'click' event is where your post-upload code is going to go. You can hide this control in a DIV with style="display:none;".
Add 2 JS functions to the page. The first one just calls __doPostBack("<%= MyLinkButton.ClientID%>", ""); Let's call this function doUpload. The 2nd one clears all of the file inputs before calling the same __doPostBack call. We'll call this on doNotUpload.
Create 2 toolbar buttons and manually edit the ASP code to include onclick="doUpload();" for the one and onclick="doNotUpload();" for the 2nd.
Add a function in your code-behind to process the LinkButton's Click event and you're done!
Note that your server-side click event needs to handle the fact that sometimes (ie when your 'Cancel' toolbar button is pressed) there are no files in your UploadedFiles collection.
You might wonder why I bother posting back if there are no files to upload. That's simple; the Upload controls are not on a separate page, but are part of my main page so I want to hide them when the user clicks on cancel.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 16 Feb 2007, 05:39 PM
Bypassing the horrid Toolbar client-side Click handler.
I know that the boys and girls at telerik central admit that the client-side handling for the toolbar is nasty; at least one of them has told me that they are looking at revisiting this to bring it more in to line with some of the other controls.
However, we don't have to wait! Each toolbar button is rendered as a DIV so you can attach whatever events you like to a button as long as they can be triggered from a DIV.
Now, I'd be going out on a limb here if I said that you could do with with impunity in your production code. I can't imagine that telerik will say that this is supported. But I would also hope that they wouldn't break it if a user did write code with this functionality in mind.
The previous post (on r.a.d.Upload) uses this functionality.
Thinking about it, I would like to think that any newly minted version of Toolbar would allow the user to tie any of a DIV's events to individual buttons. For my money, this has more value that the current idea o a single event handler for the entire toolbar.
What do you say guys?
--
Stuart
I know that the boys and girls at telerik central admit that the client-side handling for the toolbar is nasty; at least one of them has told me that they are looking at revisiting this to bring it more in to line with some of the other controls.
However, we don't have to wait! Each toolbar button is rendered as a DIV so you can attach whatever events you like to a button as long as they can be triggered from a DIV.
Now, I'd be going out on a limb here if I said that you could do with with impunity in your production code. I can't imagine that telerik will say that this is supported. But I would also hope that they wouldn't break it if a user did write code with this functionality in mind.
The previous post (on r.a.d.Upload) uses this functionality.
Thinking about it, I would like to think that any newly minted version of Toolbar would allow the user to tie any of a DIV's events to individual buttons. For my money, this has more value that the current idea o a single event handler for the entire toolbar.
What do you say guys?
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 22 Feb 2007, 10:16 AM
Watch out, watch out, the case changer's about!
OK, what's the fat bloke on about now?
Toolbar, when it renders, changes the case of your class names and so the browser can't find 'em.
My project, as you know, uses a number of telerik's components. This project is part of a much larger one and I have in place an mechnism for skinning the tools I'm using. A page (this project) has a skin name 'EcsDefault' as it happens, which is applied to each of the components. I have named each of the skin files according to the nature of the control and, where necessary, changed the class names (Grid and Toolbar require this, whereas, for example, Treeview and Upload don't). I fir up the page and, oh-er! no styling for the toolbar.
A glance at the generated HTML shows that whilst the assigned Skin name is 'EcsDefault' all of the elemnts of the toolbar use class names beginning 'ecsdefault'. Grid, on the other hand uses the case applied in the skin name.
Not being the brightest bear in the box, I failed to pick up on this at first glance and, in any event, didn't realise that the class names used by CSS were case-sensitive. Obviously, all I've had to do to 'fix' the problem is change the case of the class names in the CSS file but this just counts as another checkmark in the -ve column for toolbar.
I don't know if this applies to all versions of toolbar, but it certainly is the case for v1.4.1.
Hope this helps.
--
Stuart
OK, what's the fat bloke on about now?
Toolbar, when it renders, changes the case of your class names and so the browser can't find 'em.
My project, as you know, uses a number of telerik's components. This project is part of a much larger one and I have in place an mechnism for skinning the tools I'm using. A page (this project) has a skin name 'EcsDefault' as it happens, which is applied to each of the components. I have named each of the skin files according to the nature of the control and, where necessary, changed the class names (Grid and Toolbar require this, whereas, for example, Treeview and Upload don't). I fir up the page and, oh-er! no styling for the toolbar.
A glance at the generated HTML shows that whilst the assigned Skin name is 'EcsDefault' all of the elemnts of the toolbar use class names beginning 'ecsdefault'. Grid, on the other hand uses the case applied in the skin name.
Not being the brightest bear in the box, I failed to pick up on this at first glance and, in any event, didn't realise that the class names used by CSS were case-sensitive. Obviously, all I've had to do to 'fix' the problem is change the case of the class names in the CSS file but this just counts as another checkmark in the -ve column for toolbar.
I don't know if this applies to all versions of toolbar, but it certainly is the case for v1.4.1.
Hope this helps.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 22 Feb 2007, 10:38 AM
Grid sizing is harder than it should be!
Or maybe it's just me.
I have a 'problem' with kit not doing as I want and the Grid is a case in poiint. Now, don't get me wrong I think r.a.d.Grid it a fab piece of kit, I just wish it were easier to get it to behave the way I want.
You know what it's like, you get a project outline/spec/notes scratched on the back of a fag packet and off you trot. You write some really clever code to provide all the functionality (and more) that you've been asked for. You show it to the boss/client and they ask "Why doesn't the grid fill all the space when I resize the browser?". I'm talking about cases where you've got scrolling enabled. You have to set scrollheight in ClientSettings and you can't set it to a percentage of, well anything! At least I've not found a value that produces a useful result.
Clearly, I have no knowledge about what the guys at telerik central have done to get the grid working as it does, but I imagine it's not trivial, but I want MORE! I'd like, for example, to be able to put a grid on the page, perhaps in a container and have the grid fill the container exactly, with scrolling of the grid enabled. I'd like the grid to properly resize if the browser window changes shape.
And why is it necessary to set the grid width to < 100% if you have the beast in a splitter pane? I know that if you don't do it then the browser puts an extra scrollbar on the screen.
OK, perhaps I'm being overly critical. Maybe this is the browser's fault (it is, after all IE).
Perhaps one of the nice chaps at telerik will explain why I can't have what I want, at least I can (try) and explain it when the boss/client ignores all of my hard work to question the empty space at the bottom of the window if he maximises the window of his browser on his unfeasisbly large monitor.
--
Stuart
Or maybe it's just me.
I have a 'problem' with kit not doing as I want and the Grid is a case in poiint. Now, don't get me wrong I think r.a.d.Grid it a fab piece of kit, I just wish it were easier to get it to behave the way I want.
You know what it's like, you get a project outline/spec/notes scratched on the back of a fag packet and off you trot. You write some really clever code to provide all the functionality (and more) that you've been asked for. You show it to the boss/client and they ask "Why doesn't the grid fill all the space when I resize the browser?". I'm talking about cases where you've got scrolling enabled. You have to set scrollheight in ClientSettings and you can't set it to a percentage of, well anything! At least I've not found a value that produces a useful result.
Clearly, I have no knowledge about what the guys at telerik central have done to get the grid working as it does, but I imagine it's not trivial, but I want MORE! I'd like, for example, to be able to put a grid on the page, perhaps in a container and have the grid fill the container exactly, with scrolling of the grid enabled. I'd like the grid to properly resize if the browser window changes shape.
And why is it necessary to set the grid width to < 100% if you have the beast in a splitter pane? I know that if you don't do it then the browser puts an extra scrollbar on the screen.
OK, perhaps I'm being overly critical. Maybe this is the browser's fault (it is, after all IE).
Perhaps one of the nice chaps at telerik will explain why I can't have what I want, at least I can (try) and explain it when the boss/client ignores all of my hard work to question the empty space at the bottom of the window if he maximises the window of his browser on his unfeasisbly large monitor.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 22 Feb 2007, 11:27 AM
Just a quick follow-up to the post about class names in toolbar.
Apparently this is a known issue and it is planned to be fixed in the next major version of the control.
--
Stuart
Apparently this is a known issue and it is planned to be fixed in the next major version of the control.
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 05 Mar 2007, 10:25 PM
I'm a bit embarrased to write this, but here we go...
I have a project that uses a number of telerik components. One of the controls this I have created consists of a Grid, AjaxManager, and c couple of Toolbars. These controls go to create what I have called my 'EnquiryGrid'.
The details of the control are unimportant, suffice to say that the Toolbars are used to create the grid's (a) CommandItem and (b) Pager.
One of the guidelines I have to follow in this project is that the end-user's clients can 'style' the components as they wish. We had a support requirement that it should also be possible to 'switch back' to or standard skins easily when attempting to problem solve.
The upshot was that I had a repository of skins in a central location all called 'EcsDefault'. This worked for the project as a whole until I started to play with the CSS files of the individual components of the 'EnquiryGrid'.
I set the skin of my CommandItem, and it worked a treat. The dataset on which I tested it did not invoke a pager. Once I changed to a different set of data where there was a requirement to page the data my CommandItem screwed. Not being the brightest bear in the toybox it took me a moment o 2 to realise that the skin 'EcsDefault' used by the pager was overwriting the 'EcsDefault' skin used by the CommandItem.
<sigh />
So, I've reconfigured my 'Skins' repository like this ...
root
- Control1
-- Component1
-- Component2
- Control2
-- etc.
In addition I've named the skins after the name of the control. So, for example, I have a control called 'EnquiryGrid'. This name forms the base of the name of all of the actual telerik controls used. It is also the name of the SkinsPath directory that they all use.
My EnquiryGrid is made up of a Grid an Actionbar (CommandItem using a Toolbar) and Pager (again using a Toolbar).
So I have a structure that looks like this ...
<repository>
- EnquiryGrid
-- EnquiryGridGrid
--- styles.css
--- Img
-- EnquiryGridActionbar
--- EnquiryGridActionbar.css
--- Img
-- EnquiryGridPager
--- EnquiryGridPager.css
--- Img
I keep all of this info for this in a configuration file called, imaginatively enough, configuration.xml. This file is read when the app starts and a structure us built to hold this data. This structure is persisted for the life of the app and is used to set the various properties when an 'EnquiryGrid' is created. The configuration for an enquiry grid looks like this...
I'm sure that I've reinvented the wheel doing this, but I douldn't (easily) find anything in these hallowed halls that suggested anyone had done anything similar. Hopefully, I'm not actually talking to myself and someone will find this useful. Either that or someone will be sat at their desk sniggering 'cos I've gone at this in completely the wrong way and they'll be along to tell me how I should have done it.
--
Stuart
I have a project that uses a number of telerik components. One of the controls this I have created consists of a Grid, AjaxManager, and c couple of Toolbars. These controls go to create what I have called my 'EnquiryGrid'.
The details of the control are unimportant, suffice to say that the Toolbars are used to create the grid's (a) CommandItem and (b) Pager.
One of the guidelines I have to follow in this project is that the end-user's clients can 'style' the components as they wish. We had a support requirement that it should also be possible to 'switch back' to or standard skins easily when attempting to problem solve.
The upshot was that I had a repository of skins in a central location all called 'EcsDefault'. This worked for the project as a whole until I started to play with the CSS files of the individual components of the 'EnquiryGrid'.
I set the skin of my CommandItem, and it worked a treat. The dataset on which I tested it did not invoke a pager. Once I changed to a different set of data where there was a requirement to page the data my CommandItem screwed. Not being the brightest bear in the toybox it took me a moment o 2 to realise that the skin 'EcsDefault' used by the pager was overwriting the 'EcsDefault' skin used by the CommandItem.
<sigh />
So, I've reconfigured my 'Skins' repository like this ...
root
- Control1
-- Component1
-- Component2
- Control2
-- etc.
In addition I've named the skins after the name of the control. So, for example, I have a control called 'EnquiryGrid'. This name forms the base of the name of all of the actual telerik controls used. It is also the name of the SkinsPath directory that they all use.
My EnquiryGrid is made up of a Grid an Actionbar (CommandItem using a Toolbar) and Pager (again using a Toolbar).
So I have a structure that looks like this ...
<repository>
- EnquiryGrid
-- EnquiryGridGrid
--- styles.css
--- Img
-- EnquiryGridActionbar
--- EnquiryGridActionbar.css
--- Img
-- EnquiryGridPager
--- EnquiryGridPager.css
--- Img
I keep all of this info for this in a configuration file called, imaginatively enough, configuration.xml. This file is read when the app starts and a structure us built to hold this data. This structure is persisted for the life of the app and is used to set the various properties when an 'EnquiryGrid' is created. The configuration for an enquiry grid looks like this...
| <enquirygrid skinroot="EnquiryGrid" skinpath="styles/skins/EnquiryGrid"> |
| <grid skin="Grid" /> |
| <pager skin="Pager"/> |
| <actionbar skin="Actionbar"/> |
| </enquirygrid> |
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 15 Mar 2007, 11:09 AM
In my continuing efforts to make myself seem as important as possible without any indication that anyone is taking any notice of me, I thought I'd share a 'discovery'.
The project I'm working on is designed to provide a web-based equivalent to my Company's thick-client app. I think I've said before that this involved the presentation of a lot of data and that we didn't want to have to produce a page for each report or even templates in to which similar reports were shoehorned.
So, we describe the layout in XML and my code creates the necessary controls on the page. Simple enough. The use can navigate from one set of data to another set of related data using navigation controls on the page that are specified as part of the report. Additionally, there is a, more general, navigation tool (a Panelbar) that they can use to pick a new starting position.
What this meant in practice was the the whole application, essentially, ran in a single page, with any report that was navigated out of being replaced with the one being navigated in to.
What I found was, though, that the code that drives and is driven by the Panelbar for general navigation and the code for manage=ing my Presentations (our name for the layouts) was getting in the way of each other. Not that they were interferring with each other, more that they mage the page bigger than I would have liked and they meant that the page had 2, distinct, paths through it.
Then I discovered radSplitter. I can now have a page that defines the splitter and the Panelbar and whose code is only responsible for managing that. The code that is executed to go to a new 'start point' simply tells the 2nd radPane to set its ContentUrl to a new page that only deals with the Presentation.
OK, I could have achieved the same thing using Frames or IFrames or somesuch, but I didn't.
So, no great shakes but once again radControls not only adds to the functionality my users get, but makes things better for me too.
The project I'm working on is designed to provide a web-based equivalent to my Company's thick-client app. I think I've said before that this involved the presentation of a lot of data and that we didn't want to have to produce a page for each report or even templates in to which similar reports were shoehorned.
So, we describe the layout in XML and my code creates the necessary controls on the page. Simple enough. The use can navigate from one set of data to another set of related data using navigation controls on the page that are specified as part of the report. Additionally, there is a, more general, navigation tool (a Panelbar) that they can use to pick a new starting position.
What this meant in practice was the the whole application, essentially, ran in a single page, with any report that was navigated out of being replaced with the one being navigated in to.
What I found was, though, that the code that drives and is driven by the Panelbar for general navigation and the code for manage=ing my Presentations (our name for the layouts) was getting in the way of each other. Not that they were interferring with each other, more that they mage the page bigger than I would have liked and they meant that the page had 2, distinct, paths through it.
Then I discovered radSplitter. I can now have a page that defines the splitter and the Panelbar and whose code is only responsible for managing that. The code that is executed to go to a new 'start point' simply tells the 2nd radPane to set its ContentUrl to a new page that only deals with the Presentation.
OK, I could have achieved the same thing using Frames or IFrames or somesuch, but I didn't.
So, no great shakes but once again radControls not only adds to the functionality my users get, but makes things better for me too.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 21 May 2007, 02:34 PM
Experience does not reduce the chance that you'll do something dumb.
Ves@telerik let me have a bit of code that I've included in a little project that I'll share here sooner or later. The test program worked fine but then I copied it to my real app (along with a couple of other changes) it refused to work.
Having spent the better part of an hour trying to figure out why I discovered that the grid I was using that had the hardcoded ID of 'Radgrid1' had it's ID reset to something completely different when a postback was processed.
This doesn't generate any errors, but subsequent postbacks from the grid, if fired from the client-side using <%= RadGrid1.ClientID %>.... don't work (unsurprisingly).
I can only assume that the drugs are wearing off.
Still, on we go...
Ves@telerik let me have a bit of code that I've included in a little project that I'll share here sooner or later. The test program worked fine but then I copied it to my real app (along with a couple of other changes) it refused to work.
Having spent the better part of an hour trying to figure out why I discovered that the grid I was using that had the hardcoded ID of 'Radgrid1' had it's ID reset to something completely different when a postback was processed.
This doesn't generate any errors, but subsequent postbacks from the grid, if fired from the client-side using <%= RadGrid1.ClientID %>.... don't work (unsurprisingly).
I can only assume that the drugs are wearing off.
Still, on we go...