A. Lots of apps do it prime example virtual girl. B. What is this about protecting your IP, cant see how you could apart from spoofing and this sends an IP, just someone else's. If you want to use the internet an IP is needed somwhere along the line, and it always goes across in the request header. The IP is the simplest thing to find out and there is now way to stop it unless all you use the internet for is email. C. Agreed, can't just use IP number because of DHCP. He who laughs last thinks slowest.

Select your aspx file. To insert code in code-behind goto the solution explorer and click the icon for code. Everything that is done on the page using <% etc. can be done here, (after all they are both server-side). You should be able to virtually copy and paste the code into the class and it will work the same. This is Microsoft's solution to separating code from content. As regards your question regarding speed. When an aspx file has code embedded on the page or in the code-behind class it is no different the first time the page is run it is compiled whichever method you choose. In other word there is not an iota of difference in speed, or performance. The major hit on performance with your application will come from 1500 lines of js whether it is code behind or on the page. About the js encryption, you are right it would affect the speed of operation as any ecryption would. I thought of another a solution to this, which would protect your js from the public but not from your ISP. It is to write an httpmodule which catches the request for a .js file. If the path is absolute reject the request. ie: If someone was to type in "http://xxx.com/xxx.js" to get your included library it would be rejected, your page request however would work just fine providing the call is not absolute. At the end of the day, they could still go in to the cache on their machine and copy the library after running your page. There is no secure way of protecting javascript. The question has to be posed is it in fact worth protecting, for the following reasons. If the person who wanted the script to put it in a commercial application, the chances are they are an accomplished programmer and would more than likely write it themselves anyway. If the person who wanted the script is a script-kiddie, what would he do with it anyway?. It is unlikely that it will be in a commercial product. If your ISP copied it you can see it and take lagal action. Lets face it Javascript is not difficult, and virtually anyone can write it. Hope this helps He who laughs last thinks slowest.

Driving cars also hurts others if you are not careful who you do it around. He who laughs last thinks slowest.

Or secretly South African and watching it on his freeware TV. He who laughs last thinks slowest.

Ah I remember, thats when men were men, Plenty of glowing valves and wires, problem with your equipment, whip off the cover and stick a new valve in. "Watch out for the buildup of oxidation on yer cathodes", whack the valve three times with the handle of a screwdriver that fix it.! Nostalgia isn't what it used to be! He who laughs last thinks slowest.

I guess a copy of the OS you are using to operate your computer is free in South Africa. As an example Mac OSX in South Africa R1500 and in the USA $150, converted into Big Mac Currency about the same No?. The problem is not money it is attitude. You are quite free to sell your shareware to a world market and receive world market prices, or would you rather that South African companies only get paid in Big Macs. Get Real. He who laughs last thinks slowest.

There is one possibility I can think of to stop the page refreshing. When a request is made to a server a status code is returned whether it be 200 (OK) or 404 (Not Found) by default, otherwise the Internet would not work. There is however a status code which does not return which is 204. On the client side submit a page as normal. On the server side page do what you have to do with the the request and finally return a staus code of 204. The page will not move. He who laughs last thinks slowest.

Check out the cache on IE and you will see the .js file He who laughs last thinks slowest.

Run the code and check out the source of the page. You will probably find that the name of the dynamic control is not what you thought it was. When a control is added .Net creates a unique ID which is what you are looking for. if you look at the properties and methods of cmbAction you will see a property for .UniqueID this will give you the ID at runtime. He who laughs last thinks slowest.

I had a similar problem. It turned out to be the Com object. The GC tidies up whenever it likes unless you force it. I tried everything getting the handle of the com destroying implicitly, forcing GC nohing worked. Once the com instance was created there was no way in hell to destroy it. Funnily enough it wasn't even a custom com it was Microsoft's own!. It looks exactly the same problem as you are having. Never did cure it. Sorry could not help He who laughs last thinks slowest.

It appears to be in your code behind somewhere as it can't load the "type". The aspx page is obviously trying to get the dll. is it a namespace thing or different class naming. should be namespace CodyASPNETTest { public class WebForm1 : System.Web.UI.Page { etc. etc. or You have published the dll to the bin folder? Hope this helps Steve He who laughs last thinks slowest.

If you put your code in code-behind everything is compiled into a DLL. You must publish the aspx pages but there won't be anything on them when using code behind. The Javascript: I have a component to encrypt/decrypt javascript on the fly, not hack proof but a big deterent. He who laughs last thinks slowest.

Damn the board did it to me too.

Reading your custom section GetConfig("customsettings")("x") He who laughs last thinks slowest.

Damn the board did it to me too.

Reading your custom section GetConfig("customsettings")("x") Hope this helps He who laughs last thinks slowest.

I get what you mean now, and it does not make sense why it should do this. I have used user controls with code-behind adding user-controls dynamic removal just about any way you could think of. and have not seen this problem. I am intrigued. Do you have a code snippet to look at. Steve He who laughs last thinks slowest.

A good partnership that works, but doesn't produce any results. The Non-programmer Always has one Guru who can do no wrong, Beleives the Guru is the source of all knowledge in the universe. Completely unaffected by anyones opinion about the Guru. The Guru's word is always Law. Ignores everyone else's opinion if the Guru says disagrees. Cannot take criticism but admits openly that he can. Immediately takes credit for anything the "code-monkeys" do, but assigns it to the Guru. Immediately condemns the "code-monkeys", emphasizing the Guru had nothing to do with it. The Guru Is patronising Is always self-righteous. Never admits to being wrong. Often writes spaghetti code, (the code-monkeys cleanup after him). Portrays on the surface to be all knowing and all powerful. Is insecure. Has wierd character traits (could be anything as long as it's weird). Cannot take criticism but never admits openly. Usually Introvert. Treats other programmers as "code-monkeys". Immediately takes credit for anything the "code-monkeys" do if the Guru didn't think of it. Immediately condemns the "code-monkeys" if the Guru did think of it. How does this partnership work?. Real easy the Guru's traits display exactly what the non-programmer wants to hear. Yes it will be done tommorow, sure thats a world breaking idea you have there, yes I can do it in my sleep, The code-monkeys can do that complete rebuild in a couple of hours. Damn I could write a book on this stuff. Anybody else seen this, or am I just plain unlucky to come across this a million times? He who laughs last thinks slowest.

Hey Mike, I have the product if you have the marketing? Steve

You have hit it right on in less words.

Hi Mark and any readers, One of the things I have found is, "Every man and his dog" has a project. The non-programmer disaster: An interesting situation that usually arises out of non-programmer derived projects is that often the originator is so involved in the project that they dont see the market for the product (if it exists!). As with most projects the Idea originates from a person who has interest in a particular market. Unfortunately virtually none of them do any market demand evaluation and instantly assume that there is a monstrous hole in the market out there for their "widget maker", after that the cast is set, no need to ask questions just blindly forge ahead with the project. Along the way programmers get sucked in with the enthusiasm usually the inexperienced type and works for nothing, assuming that the dream will bear fruit later. The result is almost always the same (99% of the time). The non-programmer concentrates on his area of experience (Usually dabbling in the GUI). The programmer concentrates on his making the thing work. The non-programmer gets overpowering and virtually impossible demands are placed on the programmer (There is no way in hell that there is not a solution, even if it is inpossible) The programmer can't explain why it is not possible because he talks in "programeze". Finally the product is released, "No Response". Whats gone wrong?. There was no market in the first place, unconvinced of this the non-programmer approaches possible clients and when he returns he informs the programmer "The client won't buy unless it makes different color widgets or anything that pops into the head of the other non-programmer who is the client". Now starts the slippery slope. Continual changes upgrades "Features". Still no clients the "Multi-color widget client is never mentioned again, he wasn't really interested anyway!". The programmer disaster: A non-programmer has an idea its a good one he may not have done market research in any case there is an obvious demand, clients are lined up ready to go. The non-programmer explains the product and the programmer agrees on moving forward. First thing is the project is well funded so the programmer starts work. The non-programmer designs the interface, (almost obligatory whether he has design skills or not, usually ends up a disaster!) first milestone is reached and gone, second, third still nothing! the thing still doesn't work. The problem is that the programmer has outreached his capabilities and jumped in head long. So a decision

In your case I can see whay the licenses.licx is required. Even although you have wrapped the original control in a dummyshell it is probable that the dummyshell actualy creates an instance of the control anyway, which causes the licensing to kick in. The licensing is in the constructor. The theory I have in my case is something to do with the path of the lic file being in a web. The License provider seems not to deal with this situation. Originally I wrote new license providers assuming that the implementation would be a walk in the park. Just to get it right I decided to do a quick test using the basic license provider and it didn't work!!. I am probable wasting time trying to get the basic license provider working and should just launch straight into implementing my custom provider. Hope my comments helped in your case. Thansk for your efforts anyway.