snarfblam

Here are my findings: I think that this line is killing you: [color="Blue"]using [/color](Graphics gr = [color="Blue"]this[/color].CreateGraphics()) The problem is probably creating a Graphics object on a HWnd for a layered window. GDI+ probably isn't really designed with layered windows in mind, and things seem to be getting hairy when the Graphics object acts directly on the HWnd. I tried creating a Bitmap with the dimensions of the Form and initializing it to transparent, then setting it to the Form's background. Then I did all the drawing with a Graphics object created on the Bitmap. To erase, I used a transparent Pen with the compositing mode set to SourceCopy. Using this method, both drawing and erasing worked properly. The problem is that, when using a background image, you need to invalidate the form every time the image changes (i.e. every time you draw anything), and the performance hit is very painful. But that should get you going in the right direction. Another problem you have is that your external Windows API declarations aren't right. When I first tried to run the app I kept getting stack imbalance issues and had to correct same of the definitions.

Have you tried setting the Graphics.CompositingMode to CompositingMode.SourceCopy and drawing with Color.Transparent (or a Pen with said color)? The SourceCopy mode specifies that transparency should overwrite the existing pixel data rather than blending with it. Of course this all depends on how you've achieved transparency. There is the pseudo-transparent route (copy a screen image, paste it on your form, then draw on top of that), you could use regions, a transparency key, or layered windows. The correct solution depends on your approach.

It seems odd to me that he string builder doesn't work. Can you post the code that sends/processes the message? Maybe you could allocate some global memory to store the string in, and then send the handle to that memory to the target app. The target app would be responsible for releasing the memory. It appears you could do this with the API methods GlobalAlloc, GlobalLock, GlobalUnlock, anu GlobalFree.

It seems to me that you don't have a great handle on the way that control painting works. I understand that it's not that simple. Consider these tips. Your control should not be invalidating anything while it is painting, especially its parent. Painting is the result of invalidation, and not vice-versa. A control should not be drawing to anything but its own client region using the provided graphics object when painting. You should not explicitly invoke the Paint event or the OnPaint method. Windows will invoke these for you when a control is invalidated. You should only be invalidating a control when its visual state does not represent it's logical state (i.e. it is invalid, and therefore should be painted). A control should not invalidate its chrilden. Windows does this for you automatically.

Among the exceptions that can be thrown from the Image.FromFile() method, per MSDN:

Maybe the control can handle its parent's paint event and do the rectangle drawing there. To do this you would have to explicitly invalidate the parent whenever the rectangle moves, and the result may not necessarily look that good. You could also try to draw the rectangle outside of the paint event, but if your control is transparent it wont look right when they overlap.

There is something fundamentally wrong with your method if yau are getting this recursion. It seems to me that a control shouldn't be drawing to anything but itself in the Paint event. I'm not sure exactly what you are trying to achieve.

It seems to me that the ItemActivate event is specifically intended to be input-method agnostic. If you need to differentiate, you can use the DoubleClick and KeyPress events (KeyDown won't catch the keyboard repeat), and forget about the ItemActivate event. Note that these events appear to be triggered after the ItemActivate, but there is no good reason to make any assumption about the order the events will fire in. It might vary between OSes or WinForm versions.

I notice one difference: in the original loop, while ( [color="Red"]nUnits--[/color] ) { // Perform a byte swap of the data when retrieving it from the buffer nSum += SwapEndian(*pBuf++, nWordWidth); } return nSum; the loop terminates when nUnits = 0. In the C# code, while ([color="Red"]nUnits >= 0[/color]) {// Perform a byte swap of the data when retrieving it from the buffer nUnits--; nSum += SwapEndian(*pBuf++, nUInt16Width); } return nSum; the loop terminates when nUnits < 0, resulting in an extra iteration. Otherwise everything looks fine, but it's real easy to miss the small details when doing binary operations.

Just curious. Why are you setting the opaque flag to true on a transparent control?

I think the best method in an inheritance scenario is a virtual method. The inheriting class can override the method to add logic and then call the base method. In your example, you could have the prorerty setter call a virtual method that inheritors override. The following would work with the strings you used ("I am xxx"). public abstract class ZBase { string _test; public ZBase() { _test = string.Empty; } public string TestString { get { return _test; } set { _test = value; [color="Red"]OnTestStringSet(value);[/color] } } [color="Red"] protected virtual void OnTestStringSet(string value) { }[/color] } public class MyData1 : ZBase { public enum DbType = { None=0, This=1, That=2 }; DbType _type; public MyData1() { _type = DbType.None; } [color="Red"] protected overrides void OnTestStringSet(string value) { _type = (DbType)Enum.Parse(typeof(DbType), value.Split(' ')[2]); }[/color] } public class MyData2 : ZBase { public enum DbType = { None=0, Here=1, There=2, Expired=4 }; DbType _type; public MyData2() { _type = DbType.None; } [color="Red"] protected overrides void OnTestStringSet(string value) { _type = (DbType)Enum.Parse(typeof(DbType), value.Split(' ')[2]); } [/color] }

The problem is most likely the result of the way that Visual Studio serializes forms for the designer. When it sees that a control has an image property, it doesn't know where the image came from. Visual Studio assumes that the image has been set through the designer (as opposed to by the control with a preexisting resource), and unless the designer is instructed otherwise, it automatically stores a copy of the image in the form's local resource file. What I've been doing to prevent this is shadow the BackgroundImage property with a dummy property to effectively hide it from the designer. If you do this, though, then you need to remember to access the actual background image via the MyBase keyword, and if the class is to be inherited then you would need to create a new property or new methods to access the image.

I'm pretty sure that the > and < operators compare the values of character codes, similar to how these operators would be expected to work with the Char data type. For example... Console.WriteLine("113" < "90") The output of that code is "TRUE." It shouldn't be unreasonably difficult to write code that extracts the different parts of the version string. Then you should use Integer.Parse to convert the strings to integers so you can use > and <.

Using the following code, the program compiled and executed as expected: List<String> m_QueryList = new List<string>(); string str = "some Text"; Stream stream = new MemoryStream(); m_QueryList.Add(str); BinaryFormatter binFormatter = new BinaryFormatter(); binFormatter.Serialize(stream, m_QueryList); //stream.Close(); stream.Seek(0, SeekOrigin.Begin ); List<string> m_recvdList = (List<string>)binFormatter.Deserialize(stream); stream.Close();

[PLAIN]Simply place and around your VB code, like so: SomeFunction() 'SomeComment And it will come out like so:[/PLAIN] SomeFunction() 'SomeComment My biggest criticism would be your use of non-descriptive variable, control, and function names for exactly the problem we have here: I can't understand what is going on so I don't know how to help. Besides it being difficult to understand the overall gist of the code, it's hard to decipher what, particularly, each individual line of code does because it isn't clear what the variables represent, where their values come from, or what a function does (or why it was called). The code below is a lot closer to what I would hope for in terms of readability. I don't expect you to use the code, just notice how and where variables are declared, named, and used. Public Function Subtract(ByVal a As TextBox, ByVal b As TextBox) As Integer Return Integer.Parse(a.Text) - Integer.Parse(b.Text) End Function . . . Dim armChassisPoints As New ArrayList Dim armSpindlePoints As New ArrayList 'The comments you had here become unnecessary. It is self-commented with descriptive variable names armChassisPoints.Add(Subtract(chassisAStart, chassisAEnd)) armChassisPoints.Add(Subtract(chassisBStart, chassisBEnd)) armChassisPoints.Add(Subtract(chassisCStart, chassisCEnd)) armSpindlePoints.Add(Subtract(chassisAMid, chassisAEnd)) armSpindlePoints.Add(Subtract(chassisBMid, chassisBEnd)) armSpindlePoints.Add(Subtract(chassisCMid, chassisCEnd)) ' Call length function -- but do we need a comment to realize this? dlink1 = Length(armChassisPoints, armSpindlePoints) dlink = dlink1 errorig1 = errorigsum(dlink) loopStep = Integer.Parse(stepSizeInput.Text) loopEnd = Integer.Parse(loopEndInput.Text) 'There should be a comment explaining why the step value is the same as the starting value For index As Integer = loopStep To loopEnd Step loopStep 'Variables can be initialized on declaration, but I commented them out altogether 'because they aren't necessary in the posted code 'Dim chast As ArrayList = armChassisPoints 'Dim spint As ArrayList = armSpindlePoints ' Link 1 Chassis Movement dlink = dlink1 dLinkt1 = MoveChassis(armChassisPoints, armSpindlePoints, index ) errt1 = errmove(dlink, dlinkt1) 'Also commented out because they arent necessary as far as the posted code goes 'ca1c = armChassisPoints 'ca1s = armSpindlePoints Next index The code may look slightly more cluttered, but others (and you a year down the road) can see what it does a lot more clearly.

This thread on Stack Overflow may be worth reading.

You need to specify where to begin copying to when calling Array.Copy using a different overload (at least with InputArray2, since you don't want to copy that to the beginning of OutputArray). ReDim OutputArray(InputArray1.Length + InputArray2.Length - 1) ' Parameters are sourceArray, sourceOffset, destArray, destOffset, length) Array.Copy(InputArray1, 0, OutputArray, 0, InputArray1.Length) Array.Copy(InputArray2, 0, OutputArray, InputArray1.Length, InputArray2.Length) In the last line, the code specifies to copy InputArray2 starting where InputArray1 left off (the second to last parameter).

Don't take this the wrong way, but your code makes me want to cry a little. Treating textbox text like numbers and throwing cryptically named arraylists around is bound to make the program prone to chrashing spectacularly. Just so you know, there are and [Code] tags you can use to make the code more readable. As far as the code itself, I highly recommond enabling option strict. It helps identify potential problems with invalid type-casting (i.e. treating a string as a number when it could contain something else). I know you didn't ask for tips on general programming practices but it is hard to answer your question because your code is difficult to follow. Some of your code doesn't make much sense. You are assigning the value of ca1co to chast, then passing it into the charmove function, which may or may not be modifying it (I don't have that code). If you assign ca1co to chast, they both point to the same ArrayList and changing one changes the other. I also see you assigning a new ArrayList to every variable in the declaration, then immediately assigning a different ArrayList to the same variable (from another variable). It looks like you might have some misunderstanding about exactly how ArrayLists work (or you may even misunderstand how reference-type variables work, I don't know). I would post some code, but I don't really understand what the code is supposed to do.

Are you sure that this is C# and not C++?

The conversion to VB.NET would be doable. I really can't say what the performance difference will be, but if I had to guess I would say it would help. I believe that DotNet has faster file access, but I don't know if there would be a performance hit when it comes to Office interop. As far as what you would need to know to convert it, you should probably read a quick tutorial written for those moving from VB6 to VB.NET. The differences you need to pay attention to are the minor syntax changes, data type changes (Long becomes Integer, Integer becomes short, etc.) and you should research the FileStream class. Generally speaking, the best optimizations are algorithmic. I haven't analyzed your code, but before translating to VB.NET you might want to do some timing of your code and see where you are spending the most time. You may have a bottleneck that can be addressed by modifying your approach. Either way, we'll be glad to answer any questions about the particulars.

When you load the plug-in DLL you should be able to store a reference to the loaded Assembly object, which you should then be able to return later within the CurrentDomain_AssemblyResolve() method. (This wouldn't entail referencing the assembly at design-time.) In other words, Assembly pluginAssembly; [color="Blue"]public void[/color] LoadSomePlugin(){ pluginAssembly = Assembly.LoadFrom(someFilename); [color="Green"]// Create objects, do whatever[/color] [color="Blue"]static [/color]Assembly CurrentDomain_AssemblyResolve([color="Blue"]object [/color]sender, ResolveEventArgs args) { [color="Blue"]return [/color]pluginAssembly; }

The short answer is that DotNet does not support any blends except for your standard alpha blend and source copy. In the past I've written my own drawing functions to do more advanced blending. If you are using 32-bit sources and destinations then once you understand how to directly access bitmap data then it is quite doable.

If you don't pre-load the assembly before the CurrentDomain.AssemblyResolve event, will an exception be thrown? If so, what if you simply store a reference to the DLL and then in the CurrentDomain.AssemblyResolve event return the cached reference to the loaded assembly, rather that calling Assembly.LoadFrom() again. Either way, I doubt the assembly is being loaded more than once. I would hope that the second time around it would return a reference to the already-loaded assembly.

The originating assembly needs to be loaded in memory to deserialize an object, which means if it isn't referenced at design time it must be loaded dynamically, probably using the Assembly.LoadFile() method.

If you need to add an array of items to a list after the list has been created, there is the ArrayList.AddRange() method (or List<T>.AddRange() method), which allows you to insert an entire array, list, or any other collection to the list.