I recently built a .NET image processing application using the AForge.NET library. The program works fine on all of the 10 computers at my place of business where it is installed except for two. On these two computers, when the user attempts to crop an image, it does not crop at the proper coordinates. Everything is shifted down and to the right. The computers are a mix of Windows 7 and Windows 10 computers. The two computers exhibiting the strange behavior are both Windows 7 computers but it works on the other 5 Windows 7 computers that it is installed on. I have verified that every computer is running the latest version of the .NET Framework and tested the program on these computers with images acquired from working systems to verify that it isn't a problem with the format of their images. I am at a loss. If anyone out there has seen something like this before or has experience with AForge compatibility issues, please let me know. Thanks in advance!
I don't know how much my source code will help but here is the code for the cropping function. If additional code from other areas of the application are needed then I can provide them. Thanks again.
private void GetImage(object sender, EventArgs e)
{
int astartatX = (int)initial.X;
int astartatY = (int)initial.Y;
int aXdist1 = (int)(Final.X - initial.X);
int aYdist1 = (int)(Final.Y - initial.Y);
Crop anewcropper = new Crop(new Rectangle(astartatX * 8 - 125, astartatY * 8 - 125, aXdist1 * 8 + 250, aYdist1 * 8 + 250));
Bitmap bmpToCrop = (Bitmap)Editor.Image;
Bitmap anewcroppedImage = anewcropper.Apply(bmpToCrop);
string processedpath = Path.Combine(pictures, baseprocessedpath);
string newbaseFilename = Path.Combine(processedpath, "comic.jpg");
string anewFilename = newbaseFilename.Insert(newbaseFilename.Length - 4, number.ToString());
bmpToCrop.Dispose();
anewcroppedImage.Save(anewFilename);
Editor.Image = anewcroppedImage;
Editor.SizeMode = PictureBoxSizeMode.StretchImage;
}
Related
I've recently developed my first windows forms app (.NET Core), and it runs great on my native machine, but I've run into some problems when deploying to others. It started out with an unhandled exception occurring related to the font size on the pages being 'NaN', so I added some exception handling logic that now allows the program to launch on other PCs, but any forms element that utilizes the Font is not showing up. I have some dynamic font scaling in the application, but disabling this didn't fix any issues, all of the text boxes and buttons that contain a font field are blank.
Since this only occurs on other PCs and not the development computer I've been working on, I realize that it could be a dependency issue, but I'm not quite sure how.
Also, just to cover my bases, I'm using the publish tool in visual studio and simply copying the .exe and .dlls that are compiled in Visual studio and then placing them on a flash drive to transfer to 2 other test PCs to ensure the application is portable.
Here's the handler that I use for re-sizing screen elements and font sizing. I added the "Nan" logic to get through the exception, but it seems there's a deeper problem, but I currently have no idea what it is!
`
private void ResizeControl(Rectangle r, Control c, float h)
{
float xRatio = Width / (float)(originalFormSize.Width);
float yRatio = Height / (float)(originalFormSize.Height);
int newX = (int)(r.Location.X * xRatio);
int newY = (int)(r.Location.Y * yRatio);
int newWidth = (int)(r.Width * xRatio);
int newHeight = (int)(r.Height * yRatio);
float newFontSize = (h * ((xRatio + yRatio) / 2));
Math.Floor(newFontSize);
if (float.IsNaN(newFontSize))
{
newFontSize = h;
}
if (newFontSize == 0)
{
newFontSize = 24.0f;
}
c.Location = new Point(newX, newY);
c.Size = new Size(newWidth, newHeight);
Font newFont = new("Segoe UI", newFontSize, FontStyle.Regular);
Font = newFont;
selectionBox.Font = Font;
}
`
After doing some logging and checking on the form sizing, it turns out that many of the buttons and other tools in the application were getting re-sized before the form was loading, and were getting set to 0. I noticed this occurring on the development PC as well. I added a flag to not do any re-sizing until after the form was loaded, and this fixed the issue on my local machine as well as the test machines.
I have made a small c# winforms program which among other stuff, prints barcodes. On some client machines where it operates, some other software for printing barcodes overrides my settings for printing the barcode and it resizes just the barcode.
If I change the code just for that machine, it either repositions the image (makes it smaller as well), or stretches it so wide that it cuts off one third of it. Currently I am only using the printing settings to set the margins to 0 and set the paper mode to landscape in the print dialog, and the image size is fixed in the printing process(I used constants). Below is the code for when the user clicks the print button, and also two constants defined outside of it.
const int barcodeX = 570;
const int barcodeY = 135;
private void Print_Click(object sender, EventArgs e)
{
DocPrint.DocumentName = "Document";
elements = 0;
PrintDialog.Document = DocumentDrucker;
DocPrint.DefaultPageSettings.Landscape = true;
DocPrint.DefaultPageSettings.Margins.Top = 0;
DocPrint.DefaultPageSettings.Margins.Left = 0;
DocPrint.DefaultPageSettings.Margins.Right = 0;
DocPrint.DefaultPageSettings.Margins.Bottom = 0;
//DocumentDrucker.OriginAtMargins = false;
if (PrintDialog.ShowDialog() == DialogResult.OK)
DocPrint.Print();
}
Also the lines to encode and print the barcode in the printing process. The barcodePoint is where the barcode is positioned, on the paper.
b.Encode(TYPE.CODE128A, "SBD" + currentItem.Text.Substring(0, 3) + currentItem.Text.Substring(4), Color.Black, Color.Transparent, barcodeX, barcodeY);
graphic.DrawImage(b.EncodedImage, barcodePoint);
The program runs fine under any other circumstances, so I have identified the problem, I just do not know how to go around the other software's settings. I have already reinstalled the drivers for the printer (no success), as well logged in as a different user on the same computer, and that made my program work. So it has something to do with the software installed on it, I just don't know what.
At first I thought it was a problem with the drivers and the OS, but I tried it on other computers and it worked fine as well. The problem persists just on the computers with the software.
Is there any way to make my program force it's printing settings for the barcode image, since the software installed on the machines always uses it's own settings? Or to make sure that the settings in my code will not be changed?
Uninstalling the software is not an option, as it is used for other processes.
EDIT: I have run the program from both my user logon (no software) and the target machine user (both on the same machine). The settings were identical in both cases, the only thing different was that on the target machine, the software was installed. What are some ways to make sure that my settings are enforced, instead of an X program overwriting them?
I am calculating font metrics in a rendering service using C# .Net 4.5 running on four computers, three running running Windows 8.1, one running Server 2008 R2, all are up to date with various updates.
In the service code I use the following to get some font metrics:
int emHeight = font.FontFamily.GetEmHeight(font.Style);
int lineSpacing = font.FontFamily.GetLineSpacing(font.Style);
I then use these values to calculate the height in pixels to render some text to a bitmap using GDI+ DrawString.
I'm setting the Graphics options as follows:
gfx.PageUnit = GraphicsUnit.Pixel;
gfx.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.HighQuality;
gfx.TextRenderingHint = System.Drawing.Text.TextRenderingHint.AntiAlias;
However the metric values being reported are different, and two machines agree it's one value and the other two agree it's a different value.
On machine 1 and machine 2 the em height is reported as 1000, on machine 3 and the server (machine 4) it is reported as 2048.
The line height on machines 1 and 2 is reported as 1213, and on machines 3 and 4 it is reported as 2371.
The resulting heights are 51 and 48, which are just different enough to cause problems.
I've been looking into font metrics and it seems you can specify the font design units per em in the font and the values are traditionally 1000 on a mac and more recently 2048 on Windows, however all machines are using the same binary font file.
Is there a way to tell the font to use design units I specify in the code rather than an arbitrary value retrieved from the operating system, OR is there a way to make this value consistent across all 4 machines by changing a system value or registry entry?
I've checked the visual DPI display settings and they are the same across devices as are the clear type settings. I'm not sure where any other settings are that will help.
Edit -
It doesn't matter what the values are, just that they are being reported inconsistently across the machines.
I'm loading the fonts using the Font and FontFamily classes and I have installed the same font files on all of the machines.
The font the issue became apparent on was FranklinGothicNew, but it affects many fonts including Eurasia, Greyhound, and Lightfoot.
I wrote a quick checking program to run on each machine to highlight the differences.
foreach (var f in fontList) {
try {
var font = new Font(f, 10, FontStyle.Regular);
int emHeight = font.FontFamily.GetEmHeight(font.Style);
Console.WriteLine("{0}: {1}", f, emHeight);
}
catch {
Console.WriteLine("{0}: {1}", f, "unknown");
}
}
first of all, I have been learning Microsoft Surface for about 1-2 months now and my project requires me to look into incorporating the use of a VNC viewer into my Surface Application.
I have looked into VNCSharp and VNCSharpWpf from VNC control for WPF application and I'm currently using VNCSharpWpf as it has better user interaction in the WPF environment although the performance is somewhat lacking compared to the viewers out there.
Here is my question, is there any difference between Microsoft Surface WPF and the default WPF in how they handle framebuffer/threads ?
I noticed that when the client attempts to draw the rectangle in the Surface environment, it will cause an exception where by the rectangle to be updated has 0 width and height.
However, when I test it on the sample code the author of VNCSharpWPF provides (WPF on Window ), the error never occur.
I tried to workaround by setting and if clause to only draw if the width and height of the rectangle decoded is not 0. Although it prevents the application from crashing, it will results in dead pixel around the screen whenever there are changes in the screen in the server-end.
I've been stuck with this situation for 1-2 weeks already and have ran out of ideas and is in need of some guidance on where I should look into
Or is there is any cool VNC viewer/server out there that I can use for my Surface project that I've missed out ?
I've been having the same issue with VNCSharp WPF on a PC, and when tested VNC Sharp for WinForms, then it worked OK.
Furthermore, When I've tested VNCSharp for WPF on Debug, then it works OK, but failed on Release.
I've wasted several hours debugging it (I've learned some parts of the VNC protocol for that matter, since I've found out that it somehow reads the width and the height of the remote device from the wrong location in the netowrk stream).
The bug is related to floats comparison. It depends on the machine you have (it might work well on some machines and on others it might not)
Please look at VncClient, Line 349:
if (rfb.ServerVersion == 3.8) rfb.ReadSecurityFailureReason();
If you, while debugging, put a breakpoint there, you will see that rfb.ServerVersion is 3.8f
ServerVersion returns a calcualted float:
public float ServerVersion {
get {
return (float) verMajor + (verMinor * 0.1f);
}
}
You should expect that since ServerVersion is 3.8, then it will execute
ReadSecurityFailureReason which reads some extra bytes that are needed for the code to work, but on Release (Ctrl+F5, since in Visual Studio Release, while the code is being debugged, it will probably work OK) those extra bytes will not be read, so the width and height will be read from the wrong location on the stream, causing it to be 0px over 0px
For demontrating my point, please take the following code, and compile it as x86 (I'm assuming that you have an x64 machine and an x64 OS, since this is the situation here):
class Program
{
static void Main(string[] args)
{
SomeVersion someVersion = new SomeVersion(3, 8);
if (someVersion.Version == 3.8f)
{
Console.WriteLine("Version is 3.8");
}
Console.ReadLine();
}
}
public class SomeVersion
{
private int _major;
private int _minor;
public SomeVersion(int major, int minor)
{
_major = major;
_minor = minor;
}
public float Version
{
get
{
return (float)_major + (_minor * 0.1f);
}
}
}
Run the code in Debug x86 (both with visual studio debugger and with Ctrl+F5)
You should see that you get the message: "Version is 3.8" on both cases.
Now change it to Release x86... Run it with F5. You should get the message.
Now run it with Ctrl + F5... WTF??, no message!
In order to fix the bug in the Vnc Sharp WPF, I've took the class RfcProtocol, and added another function:
public bool CompareVersion(int major, int minor)
{
return major == verMajor && minor == verMinor;
}
Now on VNC Client (both line 188 and 349), I've changed the code so it will compare using the new function, instead of comparing 2 floats.
Is there a way to simulate touch events in Windows 8 (and preferably in windows 7).
I know there is a project called Multi touch vista but I feel its a bit overkill and I never got it working correctly with multiple screens.
What I want to do is very simple, I want to start an app that can send touch events to Windows no need for multiple mice or any thing like that.
Can it be done or do I need a (MMV) driver to do that?
Thanks
/Jimmy
I was looking for something similar and found this article Simulating Touch Input in Windows Developer preview using Touch Injection API and sample code (C++) may answer your question. However, this seems to work only on Windows 8 (not Windows 7).
It simulates Tap, Hold, Drag, Pinch/Pan, Rotate and Cross-Slide.
Here is the touch (Tap) code:
POINTER_TOUCH_INFO contact;
InitializeTouchInjection(1, TOUCH_FEEDBACK_DEFAULT); // Here number of contact point is declared as 1.
memset(&contact, 0, sizeof(POINTER_TOUCH_INFO));
contact.pointerInfo.pointerType = PT_TOUCH;
contact.pointerInfo.pointerId = 0; //contact 0
contact.pointerInfo.ptPixelLocation.y = 200; // Y co-ordinate of touch on screen
contact.pointerInfo.ptPixelLocation.x = 300; // X co-ordinate of touch on screen
contact.touchFlags = TOUCH_FLAG_NONE;
contact.touchMask = TOUCH_MASK_CONTACTAREA | TOUCH_MASK_ORIENTATION | TOUCH_MASK_PRESSURE;
contact.orientation = 90; // Orientation of 90 means touching perpendicular to screen.
contact.pressure = 32000;
// defining contact area (I have taken area of 4 x 4 pixel)
contact.rcContact.top = contact.pointerInfo.ptPixelLocation.y - 2;
contact.rcContact.bottom = contact.pointerInfo.ptPixelLocation.y + 2;
contact.rcContact.left = contact.pointerInfo.ptPixelLocation.x - 2;
contact.rcContact.right = contact.pointerInfo.ptPixelLocation.x + 2;
contact.pointerInfo.pointerFlags = POINTER_FLAG_DOWN | POINTER_FLAG_INRANGE | POINTER_FLAG_INCONTACT;
InjectTouchInput(1, &contact); // Injecting the touch down on screen
contact.pointerInfo.pointerFlags = POINTER_FLAG_UP;
InjectTouchInput(1, &contact); // Injecting the touch Up from screen
Another article: Getting Started with Windows Touch Gestures
I haven't had a chance to try it myself, but according to this article, the simulator included with the Windows 8 Dev Preview allows for simulating multi-touch zoom and rotation gestures using a mouse.
You can see a demonstration of this at approximately 35:40 of this BUILD conference session: Tools for building Metro style apps
Further to the solution which points to the C++ Sample code for InjectTouchInput which comes packaged in the User32.dll of Windows 8, the C# solution can be found here:
InjectTouchInput Windows 8 C# not working (returns false)
Creating a virtual Hid driver appears to be the only way.