|
So, search the Web for "Parental Controls" and "Parental Filters" for proxy servers.
I see dumb people
|
|
|
|
|
Buddy,
This world does not keep spies. Think of another business. This is a VB.NET forum, not for spies.
Cool
Ben
|
|
|
|
|
How can I make a program stay on top of all other programs and never steal the focus?
thanks.
|
|
|
|
|
Ok, I did it. I admit it. I programmed myself into a corner and I need a bit of help.
I am trying to build an event registration system where clients can register to an event arbiter to receive specific events. The registrations are kept in a hashtable and the tables is keyed on the text name of the event and the table data is an address of the function I want to call whe nthe event comes in.
I have everything figured out except how to USE the address stored in the hashtable to call the public subroutine of the object that subscribed to the event.
UGH!
ANY Ideas?
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
Ray Cassick wrote:
ANY Ideas?
I'm not entirely sure I completely understood what your problem was, but have you considered using delegates as they will automatically maintain an internal linked-list of the methods you want to invoke and call them for you when you invoke the event. Let me know if I am off base here.
- Nick Parker My Blog | My Articles
|
|
|
|
|
I looked over delegates but it seemed to me that they were for cases where you already new the type of the object ahead of time. In my case I might not know the type ahead of time. The entire purpose of this is to have plug-in type objects register some functions with my event arbiter object so that when the event arbiter gets an event it can decide to pass the event on to the plug-in that has registered to get that event.
All I was really looking for was a way for the plug in to give the event arbiter the address of one of it's methods so it could be called. I have the subscription part worked out in my head but I can't figure out how to get the event arbiter to actually use the address that the plug-in gave it during registration.
I might end up rethinking this a bit and maybe using reflection to do a InvokeMember instead.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
Well, suppose you are dynamically loading assemblies, you can use reflection to determine the type and more importantly what interfaces it inherits. Assuming you were to state that all objects being loaded that want to register for services implement the IRegister interface (arbitrary, I just made that one up), you could dynamically load those objects and also register them to receive notification when the event fires. Are you looking for an example of something like this?
- Nick Parker My Blog | My Articles
|
|
|
|
|
Yes, that is what I am looking for.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
I can type up a quick example when I get home tonight and email it to you, do you need it in VB.NET or is C# acceptable?
- Nick Parker My Blog | My Articles
|
|
|
|
|
I am working in VB.NET but I can read C#..
Thanks for the effort.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
Here is a quick example in C# of some of the things you can do.
Load all assemblies based on a specified interface into a new AppDomain:
public AppDomain LoadAssemblies()
{
AppDomain appdomain = AppDomain.CreateDomain("dynamic");
string[] files = Directory.GetFiles(Environment.CurrentDirectory, "*.dll");
if(files != null)
{
foreach(string file in files)
{
Assembly a = Assembly.LoadFile(file);
if(a != null)
{
Type[] types = a.GetTypes();
foreach(Type t in types)
{
Type[] interfaces = t.GetInterfaces();
foreach(Type i in interfaces)
{
if(string.Compare(i.ToString(), "IFun", true) == 0)
appdomain.Load(file);
}
}
}
}
}
return appdomain;
}
You can then cycle through those assemblies register their event handlers that are define possibly by the interface I described in the previous post. The following is just an example of registering a few event handlers with an event.
using System;
namespace test
{
class Class1
{
public delegate void RegisterEventHandler();
public event RegisterEventHandler Register;
public void fun()
{
Console.WriteLine("Hello from fun!");
}
public void morefun()
{
Console.WriteLine("Hello from more fun!");
}
[STAThread]
static void Main(string[] args)
{
Class1 c = new Class1();
c.Register += new RegisterEventHandler(c.fun);
c.Register +=new RegisterEventHandler(c.morefun);
if(c.Register != null)
c.Register();
Console.Read();
}
}
}
Hope this helps.
- Nick Parker My Blog | My Articles
|
|
|
|
|
Is there a method of creating a game bot, an automatic player. I want to try and build a program pref with VB6 to operate a game.
Its been my head for a long time now.
Any ideas
dnh500
|
|
|
|
|
This depends HEAVILY on the game you want to control...
RageInTheMachine9532
|
|
|
|
|
I would like to control a Java client game. Which is a strategy. Very simple, click on the map to do attack this, sort of game.
|
|
|
|
|
You won't be able to interact with the Java app directly. You'll have to examine screen positions and post mouse clicks to the system to get this to work.
This will not be a trivial task. You'll be calling Win32 API's alot...
RageInTheMachine9532
|
|
|
|
|
In the subroutine below,
Sub Test(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1_Click,Button2_Click
I can use sender to find out which button was clicked.
Dim B as Button = sender
me.text = B.Text
But in this next subroutine,
Sub Test(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.MouseEnter, Button1.MouseLeave
We know the sender is Button1 and e.GetType.ToString just returns "System.EventArgs"
which we also already know.
So my question is "how do I find out which event fired MouseEnter or MouseLeave?"
Thank You.
|
|
|
|
|
Use seperate handlers if you wish to know which event fired.
Rugby League: The Greatest Game Of All.
|
|
|
|
|
Dear PaleyX,
Yes, You are absolutely right, initially I did have two separate routines to handle the two events,
but I feel that if VB.net can allow one routine to handle different events then it is not unreasonable
to be able to find which event has been fired and act appropriately.
Dim B as Button = sender
B.Name (will be "Button1","Button2" or whatever)
Where is the
B.Eventname = "MouseEnter" or "MouseLeave"
e.GetType. seems to return every thing except what you really need.
I can not believe this would be difficult to implement as it is so obvious.
Thank you for your reply.
|
|
|
|
|
gaxxx wrote:
but I feel that if VB.net can allow one routine to handle different events then it is not unreasonable
to be able to find which event has been fired and act appropriately.
Nope, not really.
All your handler is is a registered callback address. When the button gets clickedit has been told to just callback to the function that you gave it by the address you registered.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
Thank you for your reply.
It seems I will just have to wait for VB.net developers to upgrade how callbacks are handled to keep pace with the language its self.
|
|
|
|
|
Actually, the language is capable of doing what you want. The problem is that your code isn't not following better practices. Having a single sub handle two different events is not good practice, or design. On top of that, since you have to determine which event fired you waste time by checking for the event type every time your sub is called. If you keep the code seperated into two different event handlers, your handlers automatically get executed faster because the system already called the appropriate handler instead of you trying to determine which handler to call, then branching to the appropriate code yourself.
RageInTheMachine9532
|
|
|
|
|
The time difference between MouseEnter & MouseLeave events tells you exactly how long a user dwelt over a control. If you have 20 buttons on a form and wish to maintain a log file for example to see if it is possible to distinguish one user from another by statistics alone, are you seriously saying that it is better programming practice to write 40 handlers? one for each possible event?
All I am saying is that, if from inside the event handler, you were given the 'nature of the event' the simple code for the above would be something like.
Dim B as button = Sender
Open log file
write time,B.Name,B.EventType
Close log file
But unfortunately B.EventType does not exist and nobody seems to think that it is a good idea that it should. Execution efficiency is not an issue here.
I can see the reasoning behind your reply and I do thank you for your time.
|
|
|
|
|
I would do 3 things.
1) Create a LIFO stack to hold the actual event data and write it to as file as needed. The stack class would also take care of adding the time stamp to each entry
2) Create an event handler for all the MouseEnter events for each button and have this handler write to your stack class when the mouse enters buttons
Private Sub MouseEnter(ByVal sender as Object, ByVal e as EventArgs) Handles Button1.MouseEnter, ... Buttonx.MouseEnter
Dim B as Button = sender
Stack.Push(B.name,"MouseEnter")
End Sub
3) Create an ecvent handler for all the MouseLeave events for each button and have this handler write to your stack class when the mouse leaves buttons
Private Sub MouseLeave(ByVal sender as Object, ByVal e as EventArgs) Handles Button1.MouseLeave, ... Buttonx.MouseLeave
Dim B as Button = sender
Stack.Push(B.name,"MouseLeave")
End Sub
This will take you down to needing only two event handlers to cover all your 'Buttons'.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
Ray
It is news to me that you could use the stack like that!
Part of my problem is the 'culture shock' coming from VB6 to VB.net, I was just about to repost to Dave to say that I have quickly come round to his view.
Put MouseEnter & MouseLeave events in there own two handlers and then determine the sender, which is readily available.
So you would never need the 40 handlers that I implied, to solve my particular programming example.
I thank you both once more.
|
|
|
|
|
gaxxx wrote:
It is news to me that you could use the stack like that!
My bad... I meant to correct myself and say Queue (Last in First out)
I always try to think a bit loosly coupled in things like this. Rather than opening, closeing and writing to the file in each event handler just abstract that part out to antoher class and have you event handlers 'give' thier data to that class.
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|