|
It's not actually an app, I'm writing a setup script and I have a requirement to rename COM1 to COM5 during setup.
Because it's a requirement, not doing this is not an option
I was considering writing a small .net exe to do the job for me, but was stuck.
|
|
|
|
|
I'm trying to make my own Custom Control, to be more specific: a Composite Control with various Labels and Progress Bars. However I need the entire Control to act like a button so that No matter which control within the composite that the user clicks, it will still run the Click event I assign to the Control in my program. I've read that this can be done with Bubbling, but I’m having trouble understanding the concept and how it applies to my needs.
I've seen various examples of Bubbling, but I'm still uncertain because I can't see in those examples whether or not the events are "Bubbled" to the overall control's event within a program - they seem to end after the creation of the control.
|
|
|
|
|
Simply - the container type control subscribes to relavent events of it's hosted controls. The event handlers all call a
protected virtual void OnClick(EventArgs e) method that raises the host's Click event.Dave
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
So, are you saying I can have each of my controls inside a container call the OnClick method whenever they're clicked? Then the Container's "Click" event will trigger? I'm not sure I'm understanding this right.
|
|
|
|
|
Yes - a simple experiment would verify this for you.
This is the idea:
public partial class MyUserControl : UserControl
{
public MyUserControl()
{
InitializeComponent();
}
private void textBox_Click(object sender, EventArgs e)
{
OnClick(e);
}
}
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void myUserControl_Click(object sender, EventArgs e)
{
MessageBox.Show("Click Event");
}
} As you will see, the TextBox 's Click event is now 'bubbled' up to the surface by the MyUserControl .Dave
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
Hello all,
my employer Kryptiva and I have put out a first release of a new plugin for Microsoft Outlook 2003 and 2007 called echotracker.
echotracker is a mail indexer and personnal information aggregator that installs itself as an panel in Microsoft Outlook. The software isn't feature-complete but is already providing useful information about mails in Microsoft Outlook.
This is released under the terms of the LGPL 2.1 license which means it's OPEN-SOURCE! There aren't that many open-source Outlook plugin out there so I think this is interesting stuff for developers.
We need developers and courageous users to build and test first developer preview. We accept bug reports and patch on our mailing lists. I'd be glad to answer any kind of questions on this forum but we would prefer people to use mailing lists.
François-Denis Gonthier
|
|
|
|
|
You would probably be better off posting this in the Catalog.Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
Help humanity, join the CodeProject grid computing team here
|
|
|
|
|
Thanks! Will do. I'm rather new here.
|
|
|
|
|
is this [echotracker] ?
'g'
|
|
|
|
|
Yes it was before it was deleted.
|
|
|
|
|
I am in the process of coding an application wherein there is a server application running as a Windows Service on a "big, powerful" box. Scattered around the country are computers that communicate with this "Host" in real-time. There will be a few thousand "clients" connected (10K or less) at any given time.
That's the background. I've already written the Sockets logic for both server and client, and the connections are speedy (using the Send* calls), so that's not an issue.
Here is my situation and question: at a pre-determined time every day, each of these clients' data needs to be tallied/processed/whatever-you-want-to-call-it and then the client needs to be notified this processing has completed. Every client could have a different time-of-day at which this needs to be done. Is there a more efficient way than using a timer (with the appropriate Interval calculated) for each client? I was thinking that perhaps using a single timer and some sort of hashtable that associates clients with time-of-day may work. But I'm soliciting all ideas. Don't assume your idea is not good enough...I want to hear as many possibilities as I can.
Thanks.
Tim
|
|
|
|
|
I'm assumeing the tallying is being done on the "big, powerful" box. Couldn't you simply send a message back to the client when it happens? I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Thanks for your reply, but you missed my point. I'm trying to design the mechanism that determines the time has been reached to process the subset of clients whose "closeout time" (a time of day) has been reached.
|
|
|
|
|
TimWallace wrote: Thanks for your reply, but you missed my point. I'm trying to design the mechanism that determines the time has been reached to process the subset of clients whose "closeout time" (a time of day) has been reached.
I can't reach your point even now.
I just don't get what you want. I mean you need the time that has beeen reached ... whose "closeout time" has been reached
|
|
|
|
|
Remote machines ("clients") may all have a unique "closeout" time, which is a time of day at which the host process ("server") needs to do processing specific to that client. When the processing is done, the server sends a message to the client. Does this clear things up for you?
|
|
|
|
|
yep but there is nothing I could add to the asnwers offered by Mark, Anticast and others.
|
|
|
|
|
Since you are dealing with machines located all over the world the only constant would be the server, correct? In which case I would consider having it send the closeout signal rather than worry about coordianting thousands of machines; 24 hours from now is still 24 hours regardless of where you are in the world. It would certainly make it easier to update the schedules when necessary also. I know the language. I've read a book. - _Madmatt
|
|
|
|
|
The remote machines, the "clients", don't need to do anything when their "closeout" time is reached. The host process, the "server", needs to do some stuff and then send a message to the client. And the closeout times can be unique for every client (inasmuch as the number of seconds in a day permit).
|
|
|
|
|
Ok. When the client initial connects have it send a refresh interval that is stored at the server, like in a hashtable as you mention. I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Maybe you could have a table/list of all of the client's update times which is sorted in an acending manor. Then you have a single, one-time use timer that fires when the next client needs to be updated. The first thing you do in your timer callback is create a new timer that fires at the time needed for the next client in the table/list?
|
|
|
|
|
Thanks for your reply. That is along the lines of what I meant by using a hashtable in my original post. Glad to see it wasn't a far-fetched idea.
|
|
|
|
|
Anticast wrote: create a new timer that fires at the time needed for the next client in the table/list?
and what happens when the times are the same for multiple clients or close enough that the timer can't start and trigger in time? A situation that is very likely to occur with thousands of clients involved. I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I'll implement a stack or queue and add all clients to it when it is determined that their closeouts need to be processed. Processing will be done in a separate thread and locks will be used to control access to the stack/queue/whatever.
|
|
|
|
|
Mark Nischalke wrote: what happens when the times are the same for multiple clients
I would be using a linked list kind of format and at the start of the Timer callback set the new Timer to fire at _nextClient.ClientPingTime, and ...
Mark Nischalke wrote: close enough that the timer can't start and trigger in time
... if its in the future, great, if its already passed then the callback should be executed almost immedatley. If he needs more precision than that he probably shouldn't be using timers anyway.
|
|
|
|
|
Interesting puzzle... Ok, how about this...
A) Dictionary/HashTable linking client ID to a record that includes ID and next scheduled time.
B) Doubly-Linked List, arranged by time, of the same records
C) Variable (Let's call it the "Insert Point") that stores either the last element of the list (If it's too short) or a reference to the entry nearest to 24 hours from now.
So it would work like this:
1) New client connects... Check the dictionary to see if he's already scheduled (If so, nothing needs to be done). If not, go to the Insert Point, which should be set to a record -about- 24 hours from now. Shift it forward if needed, insert a new record into the Linked List with that client's scheduled time, and put the record in the hash table too.
The Linked List is used so we can efficiently insert a new item at any point, without having to reallocate the underlying array (A List in .NET is just a dynamic array).
The Insert Point is needed because it would take O(n) time to iterate through the list to find the right location. The main disadvantage to using a Linked List.
2) Instead of a timer, work directly with a continuous background thread... It runs in an endless loop... Look at the Linked List, see if the first element's scheduled time has come... If so, process it, remove it, and tack it onto the end of the list. If not, Sleep() the thread until the next one is due.
This isn't a perfect solution, but it might give you a starting point... There's one main issue with this approach. There won't be even distribution...
With this simplified process, they would be allocated as they first connected... If you find a way to distribute them more evenly, you'll need a more efficient insertion mechanism. One that comes to mind would be a 96-member sorted dictionary, with its members pointing to locations in the list that are approximately 15 minutes apart (24 * 4). You could use that to estimate the proper location, then search the list itself to get the exact spot. If you use a method like this, you'll also need to give the background thread a maximum sleep time (Don't want it sleeping for an hour, when you just inserted a new record for 2 minutes from now).
|
|
|
|