Yup - do what Larson said, this really is a simple excercise. I have no idea what VBex is so I can't comment on it but VS C#/VB allows you to simple make a class library project, compile it and reference it in other projects. Never underestimate the power of human stupidity RAH

peterchen wrote: I'd put the list of enum definitions into a separate file [and #include it multiple times] I sometimes use that technique. It wreaks havoc with some compilers' efforts to optimize #include file performance (e.g. it prevents the use of #pragma once) but it has the advantage of eliminating a lot of annoying semicolons. Both the multi-#include and the multi-line #define approaches have a certain clunkiness to them, but I've not decided which bit of clunkiness I dislike more. BTW, on one project, it was necessary for a somewhat substantial piece of performance-critical code to operate essentially identically on two data structures. The normal approach would have been to have a routine take a pointer to a structure, and then perform all operations using that structure. An alternative approach would have been for the routine to have a static copy of the structure; to update both structures the code could then copy structure #1 into that static copy, operate upon it, and copy it back, then do likewise for structure #2. This would probably have offered better performance than doing all operation using pointers (on the Z80, using 16-bit integers and pointers would have been rather slow): /* foo.i1 = foo.i2 + foo.i3; */ /* About 16+16+8+16 = 56 cycles I think */ ld hl,(foo.i2) ld de,(foo.i3) add hl,de ld (foo.i1),hl /* bar->i1 = bar->i2 + bar->i3 */ /* About 20+14+14+14+14+14+14 = 104 cycles I think */ /* Note I doubt the compiler would produce code this good */ ld iy,(foo) ld a,(iy+.i2) add a,(iy+.i3) ld (iy+.i1),a ld a,(iy+.i2+1) adc a,(iy+.i3+1) ld (iy+.i1),a but the performance overhead for having to do copy the data structure four times for every system event cycle would still have been substantial. Instead, I #included the code for the routine twice, with a few #define macros set differently for each invocation. (BTW, I just realized that since I defined the PLD for memory addressing, I could perhaps have tweaked it so that a 4K slice of address space could point to two different blocks of memory, and then put the data structure there. Water under the bridge now.)

enforce1 filename.exe command_line_arguments If the main application file name were derived from the command-line-app name, one could use absolutely identical command-line apps for any number of programs. The only time the console app would have to provide any "help" would be if the system couldn't find the main application, in which case a message to that effect should probably be sufficient. BTW, I vaguely recall an article which discussed having one application named xxx.com and the other xxx.exe but I don't remember exactly what the author was doing.

Since having written the earlier message, I've managed to delete the appropriate .INF files and pretty much convinced the system that my device doesn't exist under its old identity. I still can't get the new device to work, though. My guess is that it partially installed something in such a way as to get itself confused. Sometime I'll reinstall the OS on this machine, and when I do I can fix things then. In the mean time, I wonder how I should best contact/pester the device vendor. It seems that its .INF files contain both the default vendor/device id's and some other ones, but the device itself uses the default ones. Grrr....

Thanks for your help. I think I have a workable approach for the handoff (at least my simple test apps work fine). As for aborting an asynchronous operation, I've decided the best approach is probably to have the asynchronous receive handler call a delegate for the incoming data. That way, if I give up on receiving one type of data and want to start looking for another type, I don't need to abort the pending receive--I can simply leave it pending; when data comes in, it will go to the new delegate.

supercat9 wrote: "The documentation says to avoid using TerminateThread; Well I thought I already covered this but let's have another go. led mike wrote: Terminating threads is never considered Best Practice. On the other hand if you have no other choice then it really doesn't matter what dangers might exist. Obviously, if you do have another choice then go with the other choice. What it comes down to is if you can accomplish what is needed without terminating threads (stop the thread gracefully), do it that way, always, period. However if for some reason terminating threads is all you can do and you must do it, then it doesn't matter if there are dangers does it? Now to me that seems like a pretty simple concept. However you seem to be thinking along another line that I have so far failed to understand.

I'll have to give that a try. There are a few similar problems I have, with somewhat different parameters; the approach may work well if there are 100 groups of things, but may not work so well in a variation with 1,000 groups. Even there, though, it might not be too totally horrible if it's possible to quickly identify how many items are shared by two groups (doing 1,000,000 such match-ups might not be too horrible if they took a microsecond each, but would be annoying if they took a millisecond). I'd been debating whether it would be better to grow clusters separately, or whether it would be better to pick an item to start a cluster, and then grow that cluster until things don't fit any more, then start another cluster, etc. I suppose the best approach may depend upon the exact data to be processed, but the data won't exist until after the compressor is done. Basically, I'm trying to compress some level-design data for use on a very old video game system (Atari 2600, running off a 1.19MHz 6502 with 128 bytes of RAM and 8x4k banks of ROM). The goal will be to take a level design and process it into the format necessary for the game. I can't know what sorts of levels will be designed until I get some idea of what's likely to fit. It would be possible to accommodate 20 rooms of arbitrary data, but many rooms are going to have rows in common, so in practice it should be able to accommodate a lot more than 20 rooms. I don't know how much more, however.

Hi, you can add whatever file you want to a VS project. a text document can be edited with VS if need be, you can set its Properties/BuildAction to None even if you don't want word wrapping in (some) languages, you can turn on word wrapping in Tools/Options/TextEditor/General and turn it off for specific programming languages. and you can assign an external tool to a specific file, so you could open a project's TXT file in Notepad too. PS: the above checked on VS2008 Express, probably also true for 2005 and maybe earlier versions. :) Luc Pattyn [Forum Guidelines] [My Articles] - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets

supercat9 wrote: clever idea or bad idea A finer blend of both. For some cases, it wouldn't be meaningful to have unneeded exception clauses and for code readability purposes, you can club them into generic. Vasudevan Deepak Kumar Personal Homepage Tech Gossips The woods are lovely, dark and deep, But I have promises to keep, And miles to go before I sleep, And miles to go before I sleep!

Many of the controls I design are essentially view-only, and I expect that's not particularly unusual. Even edit controls, however, shouldn't IMHO ever block the UI thread for more than a small fraction of a second. If the control needs to do something that may take awhile, it should allow the UI thread to run in the mean time even if the control itself shows a "busy" indicator and is not functional. A recent article seems to deal with this subject, so I'll have to see what I can make of that.

The basic concept is that I have an class for objects that contain a number of objects that the class doesn't really understand in detail (an iEnumerable is a common example of such a thing, though hardly the most sophisticated) and I would like for code outside the class to be able to invoke methods on some or all of the objects within, generally passing the same parameters to all. In some regards similar to delegates, except (1) delegates are hard-wired for particular method-object pairs, and (2) there is no need to hold the method info for a delegate without holding a hard reference to the object. One class I created using this approach (which seems to work nicely, though I haven't benchmarked its behavior in a program with hundreds of classes) manages something like event subscription, but using weak references. Any number of objects may subscribe to a 'publisher' object; performing .Exec(of T) on the publisher object will cause it to call function iAct(of T).Act on any subscribed object supporting interface iAct(of T). Subscription and unsubscription are O(1), non-locking, and thread-safe; an object will be unsubscribed if it (1) gets garbage-collected, (2) uses the Unsubscribe method of the Subscription object returned when the object originally subscribed, or (3) one of its iAct(of T) functions returns True when invoked. My original intended application for this class would be in an application where a number of forms have controls that affect the same properties and should thus all affect each other. While events provide a nice way to achieve much of that functionality, all the forms need a reference to an object that will support all of the events they need. If new events are added, the linking object will have to be extended to support them. Worse, using events creates the possibility of memory or resource leaks if any objects don't get properly disposed. Finalizers won't do any good if delegates keep objects alive forever. Using my actionLink class avoids these difficulties; if I create a class called e.g. volumeChangedParam, I can call Exec(of volumeChangedParam) on my event publisher object and any subscribed object that supports an iAct(of volumeChangedParam) will have its iAct(of volumeChangedParam).Act function called. The actionLink class doesn't have to know anything about volumeChangedParam or any of the other classes it works with; additional classes could be added to support other operations. All this stuff seems to work fine, but I wouldn't want to engineer too much of a sy

I did finally figure out a way to make the serial port work reasonably, using a received-data event to hit a ManualResetEvent (if the main communication thread has set it). The code creates a new ManualResetEvent every time the main thread polls and there isn't any data available; a monitor might be better, but using the ManaulResetEvent makes it possible for another thread to set a 'hurry up and abort the current operation' WaitHandle (which could be used, along with the former, in a WaitAny). Okay - I feel that is an unfair comment. Since there seems to be a good solution using events, I'd agree that my apparent antipathy toward the authors of the SerialPort class was somewhat misplaced. The Windows communications API has somewhat dubious semantics (which probably go back aeons) and the SerialPort class is mostly just exposing them. The decision to have a timeout error always throw an exception is unfortunate, but the availability of the receive data event makes it possible to emulate the two styles of semantics that a good communications library should support: -1- Wait up to a specified time for 'n' bytes; if fewer than 'n' bytes become available in time, do not return a smaller number, but instead flag an error (or throw an exception). -2- If any data is available, return it. Otherwise, wait up to a specified amount of time (possibly zero) to see if any arrives. The Windows API is a mishmosh of these approaches, so I suppose it makes sense that the SerialPort class would be as well. Colin Angus Mackay wrote: Do you wait until you have an absolutely perfect product before going to market, or do you go to market earlier with a product that will satisfy most people? Maybe I was a bit too sarcastic, but to my mind the concept of a 'try' pattern should be a core part of any non-trivial exception-based code, except in circumstances where it's not practical to predict an operation's success without committing to the operation. Whoever made the first-chance exceptions go to the immediate window was clearly trying to encourage programmers to avoid exceptions when practical; a worthy goal, but one which requires giving programmers the tools to do that. I guess what I find most irksome/puzzling about things like Date.Parse is that I can't imagine that people could use such a function very much without its limitations quickly becoming apparent. If Microsoft had to code around the limitations of something like Date.Parse in o

Mark Churchill wrote: Searching for an integer in a large array is more a sign of bad data structure design. 40us vs 20us is fairly irrelevant when its fairly obvious you have some O(n) complexity that you want removed. O(n) algorithms are good for small data sets; poor for larger ones. What constitutes "small" may change with time. Hash tables can give very nice performance, but they can waste a lot of memory with small data sets. I was trying to decide whether my data sets would be large enough to require a hash table; it seems they are.

Luc Pattyn wrote: There is a nice List.RemoveAll() Method that accepts a predicate. Good to know. Unfortunately I need a collection that behaves like a dictionary. Perhaps the best approach would be to have something that's like a dictionary with the addition of RemoveForAll; unfortunately I know no good way to adapt the existing dictionary to fit that need except by having the removeForAll create a list of keys of objects to be deleted, which would likely take time n^2.

I hadn't thought about it for this application. The one time I tried using a ListView, I found it confusing and couldn't figure out what was going on. It does conceptually seem like a ListView might be able to do what I'm after, but it also seems complicated. I don't care about people being able to edit stuff in the log window, but select/copy would be nice. The ListBox is in some ways pretty good; the biggest weaknesses are: (1) I don't know any reasonable way to have it reformat when the control width changes (to allow wordwrap). Not a biggie, and would probably be complicated to make work nicely. (2) I don't know how to make scrolling behave sensibly (e.g. when a new item is added, scroll if the last item was visible but the new item is not; when items have to be pruned from the start of the box (e.g. keeping the last 10,000 lines) maintain the same apparent scroll position unless items on the display are getting deleted. (3) I don't know any nice way to allow text select/copy. Right now I'm using double-click as a shortcut to copy a line to the clipboard, but that's nonstandard and seems ugly. Of those, I'd say #2 is the only one that seems really bothersome. Any ideas how to deal with it?

I'm using vb.net, rather than c#, but I think I understand most of the article. A few things I'm not quite clear on, though: -1- If I declare a custom event, will all subscribers to the event use the subscribe/unsubscribe methods described therefor, and make no other access to anything to do with the event? -2- What happens to event handlers for an object that falls out of scope? If I have an object that contains a reference to another object that sends events, will the presence of the former object in the latter object's subscription list keep it alive indefinitely? -3- Is there any way to have an event subscriber keep or pass something other than a raw delegate? My guess is probably not when using the standard mechanisms, but if a subscriber could hold some data which could be passed with an unsubscribe request, efficient lock-free thread-safe subscription management would be practical.