Hi,
I have some questions regarding some of your Web Controls:

TreeView:
It has ExpandAll() property but not CollapseAll(). So, what is the equivalent to MS CollapseAll()?

CallbackPanel:
Could a Panel share more than a GroupName? It doesn't seem to work with me.

Assume I have 5 Panels on a page divided as follows:
p1 + p2 ==> GroupName=g1
p3 + p4 ==> GroupName=g2

I need p5 to share both groups, something like GroupName=g1, g2. Is that possible?

Dialog:
I wish to map all MsgBox's to a Dialog, so that whenever a MsgBox is invoked, the Dialog appears instead with MsgBox declared properties (Prompt, Style, Title) being mapped to Dialog's equivalent properties (Header, Content, Footer).

Also, can I have the content of mapped Dialog includes some MsgBox Styles, such as Information, Exclamation, Question and Critical? I mainly need the graphics if Style mapping is not applicable.

The challenge, is that I want so to be persisted across entire application. Would that be possible?

That's it for now.

Many thanks in advance.

Regards,

---

Saed Hamdan
"Man may be destroyed but not defeated" -Hemmingway

Point noted. Thanks.

Regarding CallbackPanels, the link you provided was helpful but didn't solve the situation I'm encountering.

I have 2 grouped panels, say p1 and p2. p1 wraps a TV and p2 wraps a CheckBox whose AutoPostPack is set to True. Consequently, p1 has TV ID as its TriggerControlID and p2 has CheckBox ID as its TriggerControlID.

CheckBox expands TV when checked and collapses it when unchecked.

TV is populated on demand. Also, when a node is selected it fires SelectedNodeChanged, through which it passes selected node info to some controls contained inside p2, which are not declared as Triggers in any panel since they only receive data then amend their properties to show them accordingly.

Problem1:
After collapsing all TV nodes (unckeck CheckBox), clicking any root node in order to expand (then populate its child nodes) stop working!

Problem2:
After expanding a parent node or even expanding entire tree, when a node is selected, its info are casted as desired. However, clicking any node thereafter will result in additional re-population of child nodes of clicked node's parent, i.e. duplicating child nodes!

Surprisingly, removing p1 solved both problems! However, I wish to keep it to prevent page from flickering upon postback.

Apparently, it is p1 that causes above problems. A matter of synchronizing its callbacks perhaps? How to make it properly functioning?

Appreciate any assistant.

Regards,

---

Saed Hamdan
"Man may be destroyed but not defeated" -Hemmingway

Hi,

I am not sure how you use populate on demand and raises server event/callback to together, but they definitely should not be used at the same time. That is, when you click a node, you either populate on demand, or raise a server event/callback. If you wish to do both, you should delay the server event/callback until the child nodes are populated. You can do this by handling ClientSideAfterPopulate event.

Also when you expand/collapse a TreeNode, you should skip nodes whose PopulateOnDemand is set to true. A node triggers populate on demand when both of following are true:

1. It's PopulateOnDemand is set to true;
2. It's Expanded is set to false;

So if you set a node's Expanded to true, it won't populate even if its PopulateOnDemand is set to true.

Hope this helps.

Thanks!

Hi,

I surely understand that you come from MS TV and you expect our TreeView to behave exactly like that and also provide you all the additional features. However there is one very important factor that you need to understand that our product is a different product and it is released well before MS TV. So they are different. That means you need to take the product as is. You should not expect these two products to behave exactly the same way in every aspect because no only they are different products from different vendors, but we have to maintain backwards compatibly for other users.

I believe we have already shown you many of the interfaces that our TreeView supports. With the client side interface, which I am sure you are already pretty familiar with, you should be able to implement any kind of selective clicking/expanding logic easily.

So it is my understanding that you already knew the ways, but since you used MS TV first, you keep thinking if we could implement everything the same as MS does, you wouldn’t have to change any of your code. Unfortunately that is not possible. When it comes to a bug, we will do our best to fix it as soon as possible; But when it comes to programming interface, we can not simply change it based on one user’s scenario because there are many other users using the current interface. This is the same case for our CallbackPanel control. They are developed and released well before MS UpdatePanel.

We will continue to do our best to point you the right direction and if you are confused about one or more particular features, we will be happy to help. But please keep in mind that we are a component vendor, we are not a solution provider. So usually we will not be able to give you complete solutions. That means you will need to rely on whatever available to devise the solution by yourself. Like we said before, we only give you options. You will always be the one to evaluate, choose and implement.

Thanks

I think we have been quite patient with you all along. We have been providing you very detailed explanation and workaround for a row of features to you when you were not familiar with the product. But that may have given you the false impression of that we will always provide a solution to you. That is absolutely not true. A few things I want to clarify:

1. First of all, based on a lot of your previous post, we know that you have been using our TreeView and have gotten familiar with the client side API. Based on this post, we are under the impression that you wanted to use our TreeView with our CallbackPanel because you have run into a few issues/limitations with MS TreeView;

2. You may have noticed that our product runs on both ASP.NET 1.1 and ASP.NET 2.0. MS only has TreeView since ASP.NET 2.0, and UpdatePanel is released much later than that as an additional installation. We have had both working much earlier before ASP.NET 2.0 was released;

3. It makes perfect sense for us to continue change/add features into our product. But we will not add/change things just because MS did it in a certain way. Our goal is to provide a competitive alternative for our users, not a mirror of what MS has. We understand it makes perfect sense to have both product works in a similar way can reduce learning curve for a lot of our users, but you also need to understand making the product similar is an option to reach the goal, but not the goal. We need to decide whether the option servers our goal on a case by case basis. As to the SelectAction, we have decided that adding it will not server our goal well because very few user will actually benefit it and the it’s already indirectly supported by our client side JavaScript interface;

4. Back to the CallbackPanel issues. We have already given you all the pieces. You have the ability to use JavaScript to handle tree node click. You have the ability to use JavaScript to skip tree node click. You have the ability to trigger AJAX CallbackPanel with JavaScript. Putting them all together is you will have the ability to implement whatever logic you would like and trigger the CallbackPanel conditionally. We pointed you to where you should be looking and we expect you to look into it. Like the Calendar issue you had before, we gave you a workaround but you didn’t try it and in the mean time you keep asking us why we didn’t post a new release. You need to understand that this is not how it works. We can not rush a build for you for everything.

Back to the product, I think it is important for you to understand that we can not afford to change the product every time you find something that you are not comfortable with. You do need to understand our situation. It’s true that we can, and we do keep improving the product and post new build. But we can not give you a new build every time when you find this and that to be less than perfect for your scenario even if we wanted to do. We have to maintain the product compatibility and stability and everything has to go through a full cycle, changing it too often too quick can not guarantee the quality of the product. So if you do not feel comfortable with our CP, I would encourage you to drop it and switch to MS UpdatePanel. This is the same position as before you were trying our TreeView: Take a look, see if it fits you. If it fits your need, use it. Otherwise you should not.

The bottom line is, we have a product and we serve a lot of users, so we need to be very careful when changing the product, we are not in the business of providing custom solutions. Having purchased the product does not imply that we will have to change the product whatever way you wanted, nor it guarantees it will fit you perfectly. As we have always said, we only provide you the options. That’s not to say that we will never consider offering new options, but you seem to have gotten the impression that we must implement an option whenever you felt it is needed. This is absolutely not the case.

Hope this clarifies our position. This issue is now closed.

Thanks

Thanks for understanding.