|
You could look into the SlidingExpiration property.
|
|
|
|
|
Hello guys.
Can we create C#.Net Application for Symbian OS ?
Is it possible ?
Thank you.
|
|
|
|
|
I may be mistaking, but I think there is only the MONO implementation that makes it possible to run the .Net framework on a Linux/Unix machine (and therefore also Mac I presume), and it supports only the versions 1, 1.1 and 2.0 of the framework currently. This is really a gigantic work and it is not done by Microsoft, I don't think it is possible.
Jean-Christophe Grégoire
|
|
|
|
|
It does not make the .NET Framework run on Linux. The ".NET Framework" is Microsoft's implementation of the Common Language Infrastructure specification. Mono is an open source implementation of the same spec. The two are "kind of" compatible, but Mono is not a one-for-one replacement for .NET, nor is it a tool to run a .NET app on Linux.
|
|
|
|
|
I don't know if Mono[^] runs on Symbian, you may want to take a look at this site.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
|
|
Hello everybody,
I created a bitmap, 10 x 10 points, where each point has different color, using LockBits, and UnlockBits. Now I want to display it on a form, but on bigger scale. I used for this
Bitmap bmp = new Bitmap(10, 10, PixelFormat.Format24bppRgb);
Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height)
…
Here I put some data to my bitmap
…
Rectangle newRect = new Rectangle(0, 0, 100, 100);
g.DrawImage(bmp, newRect, rect, GraphicsUnit.Pixel);
As a result my image on a screen looks like this: first colomn displays half width and first row dysplays half width. All the rest looks normal. Could you please help me figure out how to fixed this?
Thank you in advance
|
|
|
|
|
Hi,
I have encountered similar effects; it is probably due to a "nearest neighbour" interpolation, which can be compensated for by shifting the coordinate system over half a pixel (fortunately GDI+ uses floating point coordinates). I don't recall the details on how to do exactly that, but you got the picture...
|
|
|
|
|
|
Additionally to what Luc said, you can also try to change the InterpolationMode property of the Graphics object. I don't see an enum value for turning it off, though, maybe Low will help.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I tried to set
Graphics g = this.CreateGraphics();
g.InterpolationMode = InterpolationMode.NearestNeighbor;
differenct mode and only NearestNeighbor gave me clear pixels as squares, all the rest creates some bluring images.
Thanks
|
|
|
|
|
Member 1980999 wrote: differenct mode and only NearestNeighbor gave me clear pixels as squares
Yeah, this may be the right one for you. NearestNeighbour doesn't invent any new colors but just interpolates from existing ones, so no blurring in this case.
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Hi,
there is no OFF position, a scaling algorithm needs some way to decide what pixel to use.
all but NearestNeighbor calculate new pixels, i.e. perform real interpolation, which normally is good,
but may ruin a synthetic image like yours.
NearestNeighbor copies an existing pixel, it is like rounding real coordinates to integer ones.
unfortunately the one you want is not provided; it could be called LeftNeighbor, corresponding to
rounding down, i.e. the floor function. However a shift by 0.5 turns NearestNeighbor into LeftNeighbor.
|
|
|
|
|
Hi all.
I've had a DataBase[^] that named Database1.mdf
After that VS2008 SP1 creates a DataSet in my Project, named Database1DataSet
Then I've created a TableAdapter[^].
Now I wanna update the DataBase with them ( DataSet & DataTable & TableAdapter ).
I used this code :
Database1DataSetTableAdapters.eventsTableTableAdapter eventsTableTableAdapte =
new WpfApplication1.Database1DataSetTableAdapters.eventsTableTableAdapter();
Database1DataSet.eventsTableDataTable eventsTableDataTable =
new Database1DataSet.eventsTableDataTable();
eventsTableTableAdapte.Fill(eventsTableDataTable);
var id = (from c in eventsTableDataTable.Distinct()
select c.id).Last();
id++;
DataRow newDataRow = eventsTableDataTable.NewRow();
newDataRow["event"] = "event" + id.ToString();
newDataRow["date"] = id;
eventsTableDataTable.Rows.Add(newDataRow);
eventsTableTableAdapte.Update(eventsTableDataTable);
eventsTableTableAdapte.Dispose();
eventsTableDataTable.Dispose();
But the changes not apply to the DataBase , Why ? 
What's wrong with it ?
Many thanks in advance.
|
|
|
|
|
Lets say I have a hypothetical class which does something and upon error throws exception as below:
public class Do
{
void DoSomething()
{
// do a few things
// do a few more things
if (SomethingWrong())
throw // some exception here
}
}
I understand I have the option to either create my own custom exception, throw the exception, or simply create a new Exception object and add my own message to it and link the inner exception to it.
My question is which of the above option is more ideal? Or should I throw ApplicationException?
Also in client code, which of the following is a better programming habit:
try
{
SomethingWhichCanThrowExceptionA();
SomethingWhichCanThrowExcepitonB();
// Some code here which does things and will not throw exception
}
Catch(ExceptionA)
{
// Recover
}
Catch(ExceptionB)
{
// Recover
}
Or:
try
{
SomethingWhichCanThrowExceptionA();
SomethingWhichCanThrowExceptionAPassed = true;
}
Catch(ExceptionA)
{
// Recover
}
if (SomethingWhichCanThrowExceptionAPassed)
{
try
{
SomethingWhichCanThrowExcepitonB();
SomethingWhichCanThrowExceptionBPassed = true;
}
}
Catch(ExceptionB)
{
// Recover
}
if (SomethingWhichCanThrowExceptionAPassed && SomethingWhichCanThrowExceptionBPassed)
{
// Some code here which does things and will not throw exception
}
Please shed some light on this or provide your own suggestions and how you do things.
|
|
|
|
|
Hi,
IMO and unless a pre-existing Exception type fits the bill accurately (as in NullReferenceException),
you should create your own Exception type, give it an appropriate name ending on "Exception" and
derive it directly or indirectly from Exception or better yet ApplicationException; even do consider a hierarchy of Exceptions.
The advantage is you (and the users of your class) can then catch your new exception type(s) without
catching more global Exceptions.
|
|
|
|
|
But if all I am doing is simply reporting a message with a more friendly message, does it make sense to create custom exceptions? For example,
RetrieveStudent(string id)
{
// Do a few things
if (Error)
throw new Exception("Failed to retrieve the student with id " + id);
}
And what about the 2nd question I had?
|
|
|
|
|
CodingYoshi wrote: simply reporting a message with a more friendly message
even then, it is good practice; it is up to you to decide whether you value the precise catching it allows.
CodingYoshi wrote: 2nd question
the latter: separate try-catch constructs offer better isolation, better readability.
in the former, if you want B to happen even when A fails, your recovery code in the catch block would have to duplicate some code from the try block, which is bad.
ultimately you could consider putting each of the try-catches in a separate method.
|
|
|
|
|
Exception handling is by definition about HANDLING an exception. When you want to display a friendly message, you are not handling anything. Handling an exception is for example retrying a connection to a remote machine after a timeout exception. This is real exception handling. Another form of exception handling is finding an alternative in case of disk I/O problem... writing on another disk or requesting the user to free some space for example.
Any other thing that you might want to do, like logging or displaying a message, should be placed at one single location within your application, potentially the application controller. This "application host" component (it can be your Program.cs as well...) is supposed to do something (log, display a popup, exit the application or close the form, or whatever you think may be appropriate). But it can terminate as well, it is up to you to decide when your application is stable, and when it is not.
Exception handling means what it says, you handle an exception when you can do something with it, otherwise you leave it going up the stack till it reaches the entry point.
JC
Jean-Christophe Grégoire
|
|
|
|
|
I understand the point is to handle the exception by retrying, trying an alternative etc. but I am talking about times when you can not recover from it and you throw it to the caller and hopefully the caller can fix the problem.
|
|
|
|
|
If you cannot handle the exception or add anything meaningful to it then don't catch it.
|
|
|
|
|
Exceptions generally match with their namespace and are thrown via their public members (although, a property should never throw an exception). You are not really supposed to make plenty of exceptions for the tons of different possible problems. Exception handling is really about exception handling. A public method in System.IO.File.Read() could for example throw a System.IOException , without more. Internally, you don't have to handle that at many levels, you just leave it going up till the public method that was called. In this public method, you may indeed have a problem because another component lower in the chain had a problem, for example a network problem during the Read operation. Well, yes, then you receive a System.NetworkException for example, you catch it and rethrow a new exception of type System.IOException with the original exception provided as "inner exception". This is the normal way of doing.
So, imagine that you create a new library ComicSoft.ZipUtilities , in the simplest case possible, you can think of one single custom exception for the whole assembly called ComicSoft.ZipUtilities.ZipUtilityException which could be thrown by any public method. And when you have to throw your custom exception because something else crashed, you just give the original exception as parameter when you instantiate it.
This is really the simple and academic case, exception handling and rethrow policies is a huge debat  Exception handling can be made much more elaborate, and exceptions should ideally be forseen to be technically useful. Forsee codes, categorize exceptions, find ways to help locating the problems etc... But in its simplest form, what you should do is one or more exception for public methods, depending on the different possible feedbacks that you think will need to provide. If you start doing that internally, then it really should be to use the exception type as condition to execute real handling.
Jean-Christophe Grégoire
|
|
|
|
|
CodingYoshi wrote: But if all I am doing is simply reporting a message with a more friendly message, does it make sense to create custom exceptions?
Yes, create the custom exception class. And I would suggest that instead of "a more friendly message" you provide a message that gives more context, that is more useful to the debugger, or the person reading the log file. It is very poor practice to be outputting exception messages to the user - There lies the potential for security breaches.
|
|
|
|
|
In answer to your second question, I'd suggest using the first style, which is more concise and clearer for readers. It clearly says "DoA(), DoB if A is successful, catch and handle A errors, catch and handle B errors". It's certainly cleaner IMO.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
