|
OK, from the top of JIT dump, you got an "Object reference not set to an instance of an object." error somewhere in your OK button in a Login form. This means that you didn't check to see if you actually had an object instance before you tried to access a property or object somewhere in there. Basically, you used an object that was Nothing instead of an actual object instance.
|
|
|
|
|
I remove all code in OK Button and I assigned as nothing. But Still that error is occurring.
|
|
|
|
|
Go back to your development code and run it from there. Somewhere in your code, just follow the stack trace you got, you've got a problem where your calling methods or using properties of an object that doesn't exist, otherwise known as "Nothing" in VB.NET.
|
|
|
|
|
Ya thanx's I got my mistake. Problem in Register key creation.
|
|
|
|
|
Colleagues,
Does anyone know how to scroll the CWGraph control? Here's the behavior I want to achieve:
1. The graph's X axis spans from 0 to 3000. In the beginning, it's charting a baseline (using ChartY method).
2. Let's say, it charted to 2500, when the user initiates a certain activity of interest.
3. Graph scrolls left leaving only the last 500 points of the baseline (this is the part I don't know how to do). The rest can be discarded.
4. Plotting continues from 500 onward.
Here's the same behavior on a storyboard: http://www.prolifictec.com/filehost/CWGraph_shifting_rev01.PNG[^]
Could anybody give me some suggestions?
Thanks,
- Nick
P.S. I'm using VB6 and Measurement Studio 8.1.11.
|
|
|
|
|
Nick Alexeev wrote: S. I'm using VB6 and Measurement Studio 8.1.11.
VB6 is long dead and completely unsupported. You should put VB6 in your subject line if you want help in obsolete technologies.
Also, don't the people who wrote this grid have a forum ? I mean, EVERYONE there uses this grid, the odds are good, given it's a VB6 control, that close to no-one here uses it.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
Oh, I remember those guys at National Instruments. Not the best libraries in the world. I wasn't writing code against them, but I had to support systems using some of their work. Ugh.
You single best source of information is going to be here[^]. It's extremely unlikely that you will find any help with those controls her, or on any other forum that doesn't belong to National Instruments.
|
|
|
|
|
Dave Kreskowiak wrote: [NI Measurement Studio is] Not the best libraries in the world.
IMHO, they are pretty good. May be they have improved since the last time you worked with them. I've just started using it. I've been looking for a chart control for plotting large amounts of data in real time (8 traces, 3000 points on the screen per trace, 10 new points a second on each trace). Among the chart controls that I've tried, CWGraph from MStudio had the best performance.
- Nick
|
|
|
|
|
Nick Alexeev wrote: May be they have improved since the last time you worked with them
Not likely. I was supporting the stuff for 4 years, as recent as last summer. Very little improvement and poor design decisions abounded from the start.
|
|
|
|
|
Dave what are some of the poor design decisions in your opinion? May be you could give me a heads-up. I'd really appreciate that.
- Nick
|
|
|
|
|
I'm a little concerned about thread safety and I'm not sure how to interpret the MSDN docs in this case. I'm making use of a VB.NET Module that has a public function for the code base I am working on to log events. This logging function can be called from anywhere at any time.
The code skeleton looks like;
Module Utility
...
Public Sub LogSomething(ByVal logData as string)
...
Dim srLog as StreamWriter = new StreamWriter()
...
End Sub
...
End Module
Is this thread safe? Could this turn into an issue? The code I'm looking at hangs occasionally for no apparent reason and I'm wondering if there's any possible way this could be influencing what's happening since every thread whatever it's doing is making use of this logging function.
Thanks!
Neil
|
|
|
|
|
I would definitely put a lock around this code. I mean, it's obvious that two threads can't have the same file open at the same time. I'd also consider opening the file once and having a lock on it for the length of the program, or doing all logging to a stringbuilder and having that dump it's contents in a try/catch as a last action before the app crashes or closes naturally.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
I was thinking the log route myself, I'm not a big fan of doing it this way but it's mandated for me right now unfortunately. Sadly, the amount of logging that's actually thrown out there over the life of the code (services) would end up sucking up all the memory way before it dies naturally.
Unfortunately when it does go wrong it doesn't crash *OR* close naturally, it's still running to all intents and purposes just hanging which is what was leading me to wonder if thread contention could be coming into play.
Thanks for your response!
|
|
|
|
|
NeilPrice wrote: it's still running to all intents and purposes just hanging which is what was leading me to wonder if thread contention could be coming into play.
It's a definite possibility. Like Christian said, I'd wrap the LogSomething in a SyncLock to keep multiple threads from writing to the log at the same time. Also, since it sounds like your logging LOTS of information, I'd open the file in the first call to LogSomething and keep it open until the app closes. You can still look at the log file while the app is running, or file is open, in Notepad or some other quick'n'dirty editor that doesn't lock the file itself.
|
|
|
|
|
I wrapped a synclock around there for good measure but it turns out that was unrelated to this hanging issue I was experiencing. I think I had two lines of code outside of any kind of Try-Catch mechanism in the whole thread part of the service - it turns out apparently you have to set a variable before logging what it is 
Just about sums up my week really, I can't believe I did that =/ On the bright side I'm a lot more confident in the logging part of the code now anyway 
Thanks for your input!
|
|
|
|
|
Hi,
IMO logging should be inexpensive and as real-time as possible, hence buffering, locking, thread switching are to be avoided. I tend to open-append-close for each individual log message, since the last message before the app dies is probably the one you want to catch most of all.
The good news is File.AppendAllText() is a static and thread-safe method that does exactly that:
open-append-close without unnecessary hassle. It does perform security checks over and over, so
you'd better log to a local file without special security issues.
BTW: if you want to add an option to e-mail your log file from within the app, you really need
to copy it first, otherwise mailing it and continuing to log would interfere...
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
My listbox1 and the textbox1 (multilines properties)
When double_click the listbox1, textbox1 = data from list box
Being that the user has to do the event(double_click)several times how do i code the textbox1 to have all the the results of the events?
If the user for example double_click 3,4,5 or 6 times the listbox1, the text box must have 3,4,5 or 6 data from the listbox1 and not only one as I have now
Thanks for your help
-kikica0512-
|
|
|
|
|
Hi,
you can append text like so myTextBox.Text+=newTextToBeAppended;
(chances are you want to append an Environment.NewLine too).
when you always append text, you probably will want to have a "clear" button too.
BTW: if you change the ListBox.SelectionMode you can allow the user to select several consecutive
or non-consecutive items in the listbox (using the shift and control keys where appropriate).
Then the doubleclick handler could combine all selected items (ListBox.SelectedItems) using
a simple foreach loop and string concatenation, saving the user a lot of double-clicks (and foregoing
the need for a clear button).
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
I use this codes but no changes
Private Sub ListBox1_MouseDoubleClick(ByVal sender As System.Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles ListBox1.MouseDoubleClick
Dim newTextToBeAppended = Environment.NewLine
**** TextBox7.Text = combobox.Text & "in (select sifrazbroja" & vbCrLf & _
"from zbroji" & vbCrLf & vbCrLf & _
"where" & vbCrLf & _
"cast(case when cijena1 = " & TextBox1.Text & " then '1' else '0' end as int)"
TextBox7.Text += newTextToBeAppended
**** I want this data as many time as I double_click the listbox
|
|
|
|
|
OK,
these are the two most popular mistakes that would lead to the updated text not showing
or not showing right away:
1.
say your form class is called myForm, you have more than one myForm instance; the first one
got created and is visible on the screen, the second or later one(s) is/are created inside
the button click handler, listbox double click handler, or where ever, and that is the one
you are modifying, but since you never Show or ShowDialog it, it does
not show at all, hence you don't see the changes.
If this is the case, the right thing to do is NOT to create more than one myForm instance, and to make sure it is the first and only instance that gets modified. If more than one form class is involved, you need to either pass one form to the other (a bad idea), pass one control to the other form (a bad idea), install a public method to update a form's Control from the outside (acceptable) or a delegate and an event (best practice). There are several articles on this subject here at CP.
2.
you are performing a lengthy operation on the GUI thread, say you modify the textbox text,
then count the number of files on your disk, then exit the lisybox double click handler; as
long as the handler is busy, whatever changes it applied to the GUI Controls will not show;
the GUI will update when the handler exits though.
If this is the case, the right thing to do is NOT to perform lengthy operations on the GUI thread;
for good GUI behavior handler execution should never last longer than say 30 msec. If it
takes more, or could take more, the job must be delegated to a separate thread (a real thread,
one from the ThreadPool, a BackgroundWorker, whatever); be careful then to not let it touch
GUI Controls directly, you would need Control.InvokeRequired/Control.Invoke for that. If you need this, look it up in MSDN and read some CP articles on the subject.
Hope this helps.
PS: next time you show some code, please use the "code block" button below the edit window,
it will insert PRE tags which give a monospaced font, a background color and foremost they
preserve all formatting.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
' in ListBox1_DoubleClick
Me.TextBox1.Text = Me.TextBox1.Text & Me.ListBox1.Text & vbCrLf
Samir R. Ibrahim
modified on Saturday, February 7, 2009 1:38 PM
|
|
|
|
|
|
purva shekdar wrote: i need a code in visual basic 6 tat helps me to search all types of files in all drives of my computer
So, what are you waiting for?? Start writing it! Noone here is going to do your job for you.
Or, did you mean to ask a specific question about a problem you're having with YOUR code??
|
|
|
|
|
purva shekdar wrote: pls help me as soon as possible
Sure.
1 - stop using VB6, it was always crap and has been unsupported for a long time
2 - buy a book on VB.NET
3 - learn to use google and MSDN
4 - now the job is easy.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
