[Solved] ClientDeleteColumn and Static Client ID

[Lena]

Hello,

I have a page which opens from a master page in RadWindow. Inside it I have RadGrid with ClientDeleteColumn.
When I set ClientIDMode=“Static” of RadGrid, OnGridCreated client event stops firing and clicking ClientDeleteColumn returns JavaScript error “Cannot read properties of null (reading ‘_clientDelete’) but the codebehind delete method executes. If I remove ClientIDMode=“Static” everything looks fine, OnGridCreated fires, clicking ClientDeleteColumn gets no errors but the codebehind delete method doesn’t execute (no log entries and after reloading the page the “deleted” row returns). What could be the problem and how to solve it? Thanks!

[Rumen]

Hi Lena,

Thanks for the details! Here's what's happening and how to fix it:

Telerik AJAX controls do not support ClientIDMode="Static" because it breaks their internal client-side script wiring. This is a known, documented limitation:

• Setting ClientIDMode to Static Breaks the Telerik Controls Functionality

That's why, with Static set, OnGridCreated never fires and the $find() lookup inside ClientDeleteColumn's click handler returns null, which causes the _clientDelete JavaScript error.

Why the codebehind delete still executed with Static IDs

The click on ClientDeleteColumn still posts back to the server (it renders a real link/button that triggers __doPostBack), so even though the client-side row-removal script crashed, the postback still reached the server and fired DeleteCommand/ItemCommand as usual. That part of the plumbing is server-driven and doesn't depend on the broken client script.

Why the row reappears without Static

GridClientDeleteColumn is not purely client-side: per Telerik's documentation, it still fires DeleteCommand/ItemCommand on the server (you can even cancel the delete there via e.Canceled), it just avoids an extra dedicated round trip and syncs with the grid's next postback instead. So if the row keeps coming back after a reload, the cause is most likely elsewhere, for example:

• The grid is rebound unconditionally in Page_Load instead of only inside NeedDataSource, which re-fetches the un-deleted data and effectively undoes the delete.
  
• The DeleteCommand/ItemCommand handler isn't actually persisting the change to the underlying data store (e.g. missing SaveChanges()/SubmitChanges(), or the delete logic is being skipped/cancelled).
  

Recommended Steps

1. Remove ClientIDMode="Static" from RadGrid. Leave it at the default (AutoID/Inherit) so the grid's client-side scripts can wire up correctly.
   

2. Keep ClientDeleteColumn if you want the instant client-side row removal without an extra round trip, it will still call your DeleteCommand/ItemCommand on the server.

3. Double-check your DeleteCommand/ItemCommand handler actually deletes from your data source, and confirm the grid's data binding happens only in NeedDataSource, not unconditionally in Page_Load. This is the most common reason a "deleted" row reappears after a page reload.
   

Next Steps

If the issue persists after removing ClientIDMode="Static", please share:

• The RadGrid markup, especially the Columns section.
• The DeleteCommand/ItemCommand codebehind method.
  
• Confirmation of where/how the grid is data-bound (Page_Load vs NeedDataSource).
• A simple runnable example to reproduce the problem

This will help pinpoint exactly why the delete isn't persisting.

Regards,
Rumen
Progress Telerik