Excel will put double quotes over some fields, but only if they contain certain characters (such as a double quote) and I think some other cases, though I forget now what they are. The first time I saw it, it took a bit to figure out what was going on. At least Calc is being consistent and doing it to all fields. The first time I used Calc I needed to do the same thing - read a tab delimited file. Ii took forever for me to figure out how to do it. Why the hell is it buried inside of the csv filter? I really hate Calc for a lot of the odd, non-standard things it does, but I use it at home 'cause I'm too cheap to spring for Excel. I'm really getting close to the point where the frustration isn't worth it any more though. You get what you pay for sometimes.

----- In the land of the blind, the one eyed man is king.

In this case, it made sense to have a different name, but doing that would have made the refactoring much easier. I wish I would have thought of that at the time.

----- In the land of the blind, the one eyed man is king.

I've dealt with this issue before by using separate bitmaps. You have one smaller bitmap for display, and your full bitmap is being adjusted in a background thread. When the slider is moved, you only adjust the display bitmap, and queue up the change for the full bitmap. Once the user clicks OK on the dialog (or is idle for a long enough period), then you do the operation on the full bitmap using the final value. I'm not sure if this will work for you or not, as it really depends on the app. Also, this type of bitmap operation is trivial to multithread. There are probably some codeproject articles talking about this.

----- In the land of the blind, the one eyed man is king.

I did some refactoring a while back on some C# code that was originally mine, but someone else had taken over and added some methods. I hit a gotcha that took a bit to figure out what was going on. The code before the refactor was something like:

public class Foo
{
  // my original method
  public virtual void Method(string str)
  {
    // do something
  }

  // new method
  public void Method(string str, params object[] stuff)
  {
    if (stuff == null)
      Method(str);
    else
      // call something else
  }
}

After the refactor, it looked something like

public class FooBase
{
  // my original method
  public virtual void Method(string str)
  {
    // do something
  }
}

public class Foo : FooBase
{
  // new method
  public void Method(string str, params object[] stuff)
  {
    if (stuff == null)
      Method(str);
    else
      // call something else
  }
}

When I ran it, calling Foo.Method("string") would end up causing an infinite loop. After some serious head scratching, I figured out that the method resolver looks at the actual type first to find a match, and looks at the base only if it couldn't find one at that level. Inside of Foo.Method, it calls Method(str) - which would end up resolving to the method with the signature of Method(string str, params object[] stuff), not Method(string str). It's not quite the way I expected it to work, but thinking about it now that's pretty much how it would have to work in order to resolve overrides correctly. I ended up having to change the name of Method(string str, params object[] stuff) because there was something that inherited from Foo and overrode the original Method - so calling base.Method(str) there would simply not work. I would have changed it anyway though, because the new method really wasn't an overload of Method, but did some other things and shouldn't have the same name (it actually belonged in a separate class altogether, but that's a different story).

----- In the land of the blind, the one eyed man is king.

Have a timer that gets started in the form load event, and then do the btnScan.PerformClick() in the timer's event handler.

----- In the land of the blind, the one eyed man is king.

Same here - looked like it might be a bit of entertainment, but if I buy a game, I'd like to be able to play it no matter what. I still have a few DOS games I fire up sometimes, none of which are still supported in any way. What happens to one of these stupid DRM games when the game is no longer supported?

----- In the land of the blind, the one eyed man is king.

I know, but it seemed worse on this one - maybe I just hadn't heard a Metallica song in a while ...

----- In the land of the blind, the one eyed man is king.

Personally, I can't stand it. Each individual riff sounds great, but then it's all kind of mashed together and incoherent as a whole. I also couldn't get over Hetfield's voice, and how the end of practically every line ends like this "But the sunshine never comes_ZZZAAA_". It's OK every once in a while, but get's old when it's at the end of practically every line.

----- In the land of the blind, the one eyed man is king.

If you really want to get rid of them, charge them your going rate (or possibly more), and have a minimum number of hours per support request. Also offer them the services of a more junior dev who would be happy for the extra work. I'm sure you know someone that would fit into this category.

----- In the land of the blind, the one eyed man is king.

The more formats the better obviously - but I would probably hit 95% of the target audience by just supporting Canon and Nikon formats. I know where you're going with this, and trust me I've been there already. I have a couple books on the subject of image processing and have implemented some of the basics already. I've taken a look at the Canon SDK as well. The conclusion from this work is that the code really is generic and that I'd be doing the same work that someone else has already done - so why not just buy a library that does that and continue on with the rest of the application. This will make dev time for the app shrink significantly.

----- In the land of the blind, the one eyed man is king.

El Corazon wrote:

sorry, can't help you.... I tried for ages to find the things I need, but my software is often too specialized. General use software components are too general and my need for speed too great, so I try briefly, then give up and write my own.

I usually write my own as well, and started to in this case - but I really don't have nearly enough time to devote to most of the image manipulation needed for this project - especially making it color aware and having the ability to read in images from camera raw formats. If I can get this by spending a bit and focusing more on the core aspects of the software, then all the better.

----- In the land of the blind, the one eyed man is king.

You know - I wouldn't mind smart-ass replies so much if there were at least a real one mixed in somewhere ... :~

----- In the land of the blind, the one eyed man is king.

I'm searching for an imaging component, and having some difficulty finding one with the right features. I've been checking out ComponentSource and using Google, but I don't think I'm finding all the ones available (I swear I remember seeing one with the right features a while back when looking for something similar, but I'll be damned if I can remember the name). What other sources do you all use to find the right component packages to use in your projects?

----- In the land of the blind, the one eyed man is king.

Herbertmunch wrote:

Thats what the first invalidate does! When you call invalidate, it wont invalidate immediately. If you were to call refresh() then it would go straight to the paint code, but this way it just carries on executing the next instruction.

Yep, you're right - it's been a while since I've done much with GDI apparently, and I forgot that. However, Refresh is a bit more heavy handed - it will invalidate everything then force a redraw - if you only want to force the redraw the invalidated regions, use the Update method. Not that this matters to the issue at hand ... Anyway, I loaded this up in a test project just to see what was going on - I should have done this right away but was too lazy :) Anyway, it looks like what you're seeing is from the draw rectangle actually drawing one pixel past the edge of the rectangle (you can see this easier if you make the rectangle width to be 1, you'll see a two pixel wide line drawn). What you'll want to do is just to invalidate an area slightly larger than your rectangle - so your both of your invalidates should so something like: Invalidate(Rectangle.Inflate(r, 2, 2)). Then, assuming your paint has been updated to fill the clip region, all is working correctly. The reason you need to invalidate an area larger than the rectangle on the second invalidate as well as the first is becauase of the same issue - the pen draws one pixel to the right and one down from the actual rectangle, causing the rectangle to be clipped if moving to the right or down.

----- In the land of the blind, the one eyed man is king.

Without running your code, I'm thinking the problem is here:

        protected override void OnMouseMove(MouseEventArgs e)
        {
              //Invalidate old location
              Invalidate(r);
              r.Location = e.Location;
              //Invalidate new location
              Invalidate(r);
        }

The first call to Invalidate(r) fills the rectangle then draws it. You then move the rectangle and call Invalidate(r) again which fills the relocated rectangle and then draws it - however, there is no code that is repainting over the old rectangle. You need to keep track of the area that was under the original rectangle and invalidate the union of the old rectangle and the new one (you will only need to call invaldiate once in OnMouseMove when you do this). Also, the call to e.Graphics.FillRectangle(Brushes.White, r) in the OnPaint method will need to be adjusted to fill the clip region (can't remember the property name off hand, but should be easy enough to find).

----- In the land of the blind, the one eyed man is king.

I'd vote for Mantis as well. The newer versions contains about all the features you'll need in a bug tracker tool, and it is in active development.

----- In the land of the blind, the one eyed man is king.

This is actually pretty similar to the curriculum that I had as a student, in my last year anyway (we were the prototype for the system that I think is still in place today). For the last year, the senior students (only 6 of us) had to create a checkout system for our library for items not currently in the system. The first semester that year was dealing with the stakeholders to nail down requirements, creating a detailed design and making initial prototypes. The second semester had us managing lower level students in the creation of the final product. It was definitely eye-opening and lessons learned there have really helped me along my career.

----- In the land of the blind, the one eyed man is king.

Are there any decent memory debuggers out there that will work in a mixed C# and C++ (both managed and unmanaged) environment? I'm helping a collegue track down some problems in his code, the hunt started for a reason that the EngineExecutionException was being randomly thrown, but several AccessViolationExceptions were found after removing some "catch (Exception ex)" lines were removed, so we're tracking down these access violations first, thinking that they are perhaps some of the reasons behind the EngineExecutionException. I've used BoundsChecker in the past with great success, but it looks like this as well as pretty much every tool I'm finding is for unmanaged C/C++ only. Managed code "shouldn't" have these problems, but unsafe code blocks are used quite a bit in an effort to speed the program up (speed is very imporant to this program) - and it's looking like the AccessViolationException isn't being thrown on all of the incorrect accesses, so we're getting some corrupted memory (even had a file get corrupted that was only open for read, still wondering how that happened).

----- In the land of the blind, the one eyed man is king.

If 10 files get dropped there, you should have 10 calls to your handler. I can't remember exactly (it's been a while), but I'm pretty sure the calls come back via the thread pool so even if you wanted to process them all from one of the handler calls, you'd have to make sure that only one of the calls is actually processing the files, and not the others, with a lock or mutex of some sort. If this is for sure how you want to handle it (process from a single handler call), you could do something like this (after first making sure the code is only running on one of the handlers).

void watcher_Changed(object sender, FileSystemEventArgs e)
{
	// TODO: Make sure that this is the only handler running on these files

	string[] fileList = Directory.GetFiles(Path.GetDirectoryName(e.FullPath), "*.xml");
	foreach (string file in fileList)
		// do the processing
}

----- In the land of the blind, the one eyed man is king.

Since your Draw method makes sure that while the background thread is busy, a draw doesn't happen on the bitmap - you don't need to keep creating a new bitmap. In fact, looking at the size of the bitmap you're creating, I bet a lot of your 5-10 second draw is taken up by simply creating that bitmap object. This is of course making the assumption that your bitmap size isn't constantly changing - if that is the case, then ignore this post - if the bitmap size is (fairly) constant, then keep reading.

class SomeForm : Form
{
private Bitmap _theImage;
private bool _working = false;

void worker_DoWork(object sender, DoWorkEventArgs e)
{
// make sure the image is initialized (may as well do it on the background thread).
if (_theImage == null)
{
int width = (int)Math.Round(Width * fDPIX);
int height = LogHeightPixels;
_theImage = new Bitmap(width, height/*, System.Drawing.Imaging.PixelFormat.Gdi/*.Format32bppArgb*/);
}
// note, you may need to clear the bitmap in this method call.
// it all depends on what the draw log method is doing.
DrawLogToBitmap(_theImage);
}

void worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
_working = false;
Refresh();
}

public override void Draw(Graphics gfx, Rectangle rect)
{
gfx.ScaleTransform(zoom, zoom);

// Update the bitmap (only as needed)
if (bDirty)
{
   // I'm assuming this method starts the worker thread - if so:
   \_working = true;
   UpdateBitmap(gfx);
}

if (\_working || worker.IsBusy)
{
   gfx.DrawString("Updating Bitmap, please wait!", this.Font, Brushes.Black, new PointF(0, 0));
   return;
}

RectangleF rcSource = new RectangleF(-horizontalOffset, -verticalOffset, ClientRectangle.Width/zoom, ClientRectangle.Height/zoom);
RectangleF rcDest = new RectangleF(ClientRectangle.Location.X, ClientRectangle.Location.Y, ClientRectangle.Size.Width/zoom, ClientRectangle.Size.Height/zoom);

try
{
   gfx.DrawImage(\_theImage, rcDest, rcSource, GraphicsUnit.Pixel);
}
catch (Exception exc)
{
   gfx.DrawString(exc.Message, Font, Brushes.Black, new PointF(0,0));
}
etc....

}
}

I may have missed something (I've been up for FAR too long, and can't sleep for some reason), but that's the gist of it. You'll probably want to do a few more checks to make sure the bitmap isn't being accessed from multiple threads at the same