|
Hi,
I am creating query editor as in sql server. I have to use blue color for reserved words and black for others. I have inserted the color table in "RTF" of richtextbox , but the modifications in the "RTF" cause the index of richtextbox remains at zero.
Please tell me the reason of this.
Thanks,
Sonia
|
|
|
|
|
Index? What index of RichTextBox?? Your question doesn't make any sense.
|
|
|
|
|
Dave I think what is meant by index is the index of a thing in the table or perhaps the index of paragraph etc being enumerated in the RTF.
|
|
|
|
|
Cursor remains on the start of richtextbox.
|
|
|
|
|
Adding text to the RTB, or any TextBox for that matter, does not move the Caret. The property that controls the Caret position is SelectionStart. If you want to add text and move the Caret at the same time, use AppendText, or just set the SelectionStart property yourself.
|
|
|
|
|
I originally created a project in VS2008, converted it to VS2010. Last night, I decided I didn't want to continue using VS2010.
I then created a new project in VS2008, and copied all of the code from the original project into it. Everything compiles just fine, but the app didn't work like it did before the latest conversion, so I started up a debug session, and immediately found the problem.
When the app starts up, it fires off a BackgroundWorker object. The worker processes as normal, but when it jumps into the ReportProgress event handler,the first line of code is an if statement. It appears as if the if statement isn't being evaluated at all (I put an else clause in to see, and it's not being stepped into at all), and control is immediately returned to the RunWorker event handler.
What could I have done to the code that could possibly cause this?
Of course, I've tried the obvious remedy (clean/rebuild), but it didn't work.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Have you tried writing a trace to the output window from the ReportProgress event handler? There is probably something going on with the threading possibly the debugger isn't picking up the call to the handler due to a different thread being used.
I think it likely that VS2010 uses a different thread model to VS2008, being built using WPF, you might even have discovered a genuine bug in the VS2010 beta...
CCC solved so far: 2 (including a Hard One!)
37!?!! - Randall, Clerks
|
|
|
|
|
I've only seen this kind of thing when the debug data gets "out of sync" with the source code, and it is usually resolved by doing a re-build. However, if the project is in Release Configuration rather than Debug Configuration, then optimizations in the build could be causing it to skip the code. The thing is, it usually only skips code that it determines will never be executed. I would ensure that you are working in Debug Configuration and check the values that the if statement tests as soon as it enters the event handler. If you think the compiler is errantly determining that statement to be unnecessary and optimizing it out; stick "true && " at the front of it to force the statement to resolve to true and then re-build and re-run the code.
Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
|
|
|
|
|
true ||?
|
|
|
|
|
Yes, what was I thinking!! 
See, I was just checking to make sure the rest of you are on your toes!
Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
|
|
|
|
|
Well, it's a completely new project created in VS2008, and I only added the source files back to the project. I know for a fact there aren't any PCB files or other temporary files form VS2010 because of the way the project was created, so I'm not sure how the debug info can be out of sync.
I also verified that the project is indeed being compiled in debug mode.
The if statement isn't evaluated at all. The debugger hits that statement, and then goes right back to the runworker event handler. I suspect that putting true || in front of the existing expression wouldn't have any effect, but when I get home, I'll try it.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Did you manipulate the BackgroundWorker through the designer in VS2010? If so, it may have added some funky code to the .designer.cs file. Just a thought...
Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
|
|
|
|
|
Nope - manually added.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
I've read your OP properly and understand that you've take a project back to VS2008  .
The PDB sync is the first problem that I've encountered that might cause your error. I've had problems with clean in the past, and had to manually clear out all the BIN directories. I'd go to the extent of deleting all build "flavour" directories (bin\debug \bin\live etc). This has two effects: The PDB must be in sync; and, as has happened to me in the past, a Solution "debug" build had "live" builds hidden away in the the Configuration Manager. If you do a debug build and have anything other than debug sub-directories in your bin folder, this might be your culprit.
The only other time I've seen this problem was when an exception was raised on another thread (the UI thread in my case), and a top level exception handler caught it without reporting. To find this, switch on break on all exceptions.
CCC solved so far: 2 (including a Hard One!)
37!?!! - Randall, Clerks
modified on Tuesday, December 29, 2009 10:00 AM
|
|
|
|
|
You didn't read the whole message. I created a BRAND NEW project in VS2008 and moved the source code to it, and re-added the appropriate references to the new project. There were no PDB files brought over, and certainly no project files.
As far as it knows, it began life as a VS2008 project.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: You didn't read the whole message.
Actually I did. You are looking for possible causes to your problem everything I described in my last post has thrown up the problem you described in you OP for me in the past (without VS2010 being involved) :
a) Generally bad PDB synchronisation will cause the symptoms you describe. If you have built more than once (even with a new project), you might have bad PDB, without carrying over the ones from 2010. Clean sometimes doesn't do its job properly (at least in my experience), so a manual deletion might help.
b) I have also seen the exact error you describe because some turnip on my team changed the solution-level "debug" build configuration so it built one of the many projects under its live build. In this case the debugger was hooking into a PDB for the last debug build of that dll, again causing synchronisation problems with the code. You can spot this quickly by doing what I described in step a, and my last post.
c) I had a problem where the debugger apparently did not evaluate the line of code I had a breakpoint on (actuall, an if statement like yours as it happens).An exception was being thrown by another thread (the UI thread in my case) causing the thread running the code being debugged to be terminated, but it looked like the line of code in the debugger was not being evaluated (as you described). This one is a long-shot, but is easily spotted by getting the debugger to break on all thrown CLR Exceptions, not just the caught ones.
CCC solved so far: 2 (including a Hard One!)
37!?!! - Randall, Clerks
|
|
|
|
|
It may be stupied question, does the ReportProgressEvent fire at all?
|
|
|
|
|
Yes - go back and read the original message. The debugger steps into the event handler but the if statement but immediately returns control to the runworker event handler, apparently without evaluating the if statement *at all*.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Interesting. I would decompile it of course. I would also put a break point in to stop before it gets to the 'if' in question. Then click the decompile button in VS2008 and try stepping through the machine code.
The comment about using inline debugging statements is a good one.
I would like to hear what the result is once you find the solution, I'm book marking this thread.
Thanks John...
|
|
|
|
|
how to move multipoint button when the multipoint mouse moves
i.e it should move on multipoint mouse move event
please reply
thanks in advance
|
|
|
|
|
|
Hi Dear,
Here I am trying to upload a photo.
protected void LoadImage() {
string UserName = Session["UserName"].ToString();
byte[] Data = Profile.GetImageData(UserName);
if (Data != null)
{
MemoryStream stream = new MemoryStream(Data);
Bitmap bitmap = null;
bitmap = new Bitmap(stream);
bitmap.Save(Server.MapPath(@"~\UserPhoto.bmp"), system.Drawing.Imaging.ImageFormat.Bmp);
bitmap.Dispose();
imgPhoto.ImageUrl = @"~\UserPhoto.bmp"; } }
I have created virtual directory and trying to open it directly from browser
|
|
|
|
|
Hi,
what is that tilde doing there?
Here is a standard reply I found in the attic:
Most, if not all, errors inside GDI+ are reported as "generic problem occurred in GDI+". If the affected line is an Image.Save chances are your path is incorrect or inaccessible, your disk is full, or your destination file exists and is locked.
If you load an image from a file, most of the time the file remains locked as long as the Image is alive. This would prevent you from saving an image to the same path.
It applies to Image.FromFile, and probably also to PictureBox.ImageLocation
The one exception I am aware of is when you use Image.FromStream.
So I suggest one of these two workarounds:
Bitmap bm=null;
{
Bitmap bm1=Image.FromFile(filepath);
bm=new Bitmap(bm1);
bm1.Dispose();
}
or
Bitmap bm=null;
using (FileStream stream=File.OpenRead("image.jpeg")) {
bm=Image.FromStream(stream);
}
|
|
|
|
|
In ASP.NET the tilde at the beginning of a path represents the local file system path to the root of the application. Without it you'd have no way for the server to reliably access the local file system relevant to the application. So, for example if I have an ASP.NET application on my local machine named "TestApp", when I call Server.MapPath("~"); I would get something like "C:\Inetpub\wwwroot\TestApp".
Hold on a second here... Don't you think you might be putting the horse ahead of the cart?
|
|
|
|
|
First you should be very careful when you use GDI+ combined with ASP.NET.Microsoft warns that some GDI+ features may will cause some unexpected problems when are used with ASP.NET.
Why don't you write your own HTTP HttpHandler that handles images load from the database for example?
Life is a stage and we are all actors!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
