|
Dear dave..
thanx a lot.. your code worked..with a little modification
Shell("cmd.exe /c c:\first.exe < c:\in.txt > c:\out.txt")
thanx a zillion.
shreeya
|
|
|
|
|
I created a connection using OLE DB (ADO) to a password protected access database. I designed a report using Designer support. It is throwing error described as under:
Logon Failed.
Details: ADO Error Code: 0x80040e4d
Source: Microsoft JET Database Engine
Description: Not a valid password
SQL State: 3031
Native Error: -124782449
I am sure that I am not suppling password to report viewer. But I do not know the way.
And, Can I filter records at crystal report level?
Any Body Can Help Me.
Shoaib Nawaz
|
|
|
|
|
Sounds to me that the connection string to your access database is not in correct syntax.
Check it here http://www.connectionstrings.com
Cheers
|
|
|
|
|
To date have only written application with one form so do not laugh. Now I have a application with the need for more than one form.
I placed a button on the primary form to launch another form. The code I placed in click event is:
Dim frmTable as Form
frmTable.activate
But it tells me: " An unhandled exception of type 'System.NullReferenceException' occurred in Snow Loads.exe
Additional information: Object reference not set to an instance of an object."
I know this is a silly question but any help
|
|
|
|
|
Dim frmTable As New Form2
frmTable.Show()
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Thanks for reply
I tried
Dim frmTable As New Form2
frmTable.Show()
It did not like Form2
I tried
Dim frmTable As New Form
frmTable.Show()
This gave me the same error previously noted.
|
|
|
|
|
SoonerFan wrote:
I tried
Dim frmTable As New Form2
frmTable.Show()
What is the name of the form you are trying to instantiate? You need to change Form2 in the above code to whatever you have named it in your project (i.e. if it is called "TableForm" then the code becomes:
Dim frmTable As New TableForm
frmTable.Show() The second form must be defined in the same project as the form from which you are trying to display it.
Simply creating an instance of an undefined Form object will cause the error you are seeing.
You could also try this code since it is a better idea to separate the Dim and the New operations for reasons we won't get into here:
Dim frmTable As TableForm
frmTable = New TableForm
frmTable.Show()
...Steve
-- modified at 22:47 Wednesday 28th September, 2005
|
|
|
|
|
Steve Pullan wrote:
You could also try this code since it is a better idea to separate the Dim and the New operations for reasons we won't get into here:
Don't take this as bashing you or anything, I'm just curious what the reasoning behind this is. I've never seen anything that says it's a bad idea.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Dave, This entry from http://www.vb-helper.com/howto_test_dim_as_new_speed.html explains it better than I can, however I have been programming VB this way for ages for the same reasons. Granted that the efficiency gains are questionable especially with the fast processors of today, it is considered (by me) to be a good programming practice to separate the definition and instantiation/initialization of objects. I have not really investigated this with VB.NET and I'm prepared to be corrected if this is no longer the case. Thanks for asking.
From VB Helper:
When you declare a variable Dim X As New ..., Visual Basic doesn't actually initialize the variable until it uses it. Every time you refer to the variable Visual Basic needs to see if the variable has been initialized and initialize it if it hasn't. It essentially does something like this:
If X Is Nothing Then allocate X
Now do what the program says
The idea is Visual Basic cannot really know apriori whether the variable has been allocated yet.
If you declare the variable and initilize it separately, Visual Basic assumes you know what you're doing and that you will allocate the variable before you use it. If you don't, it raises an error.
...Steve
|
|
|
|
|
Hmmm...Didn't know that about VB6. Seems like a waste of processor time checking to see if the instance exists. Do that a couple hundred thousand times in a loop...
But, I don't think that's the case with VB.NET. I'd be willing to check into it later today.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I need help. I get a run time error that too many rows to output, based on limitation specified by the output format. I'm using VBA to export a Access table to Excel using below code:
DoCmd.OutputTo acOutputQuery, "EXPORT_LOUDAL_DC", acFormatXLS, "C:\MLE_Export\289 204 DC " + txtAddto + ".xls", 0
There are approx 18,000 rows. This code worked for months until the rows exceeded 16,000. Since Excel can handle 64,000 I'm not sure why the error.
Can any help. By the way... I'm a user not a programmer!
Thanks
|
|
|
|
|
It's not the number of rows, but the number of cells you're filling. Excel has it's limits, I don't know if/where they're documented, but you can't fill every cell of an Excel worksheet with a value, no matter how much memory you have in the machine. You've simply exceeded Excel's capacity.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
just wondering: is there anything that VB.NET can do that C# cannot? i noticed some of the Enterprise Library was written in C#, which is why i can't use it. which angers me, but i guess i'll just have to spend the $600 to...
anyway, back to the question.
is there anything one can do with VB that one can't do with C# or vice versa?
|
|
|
|
|
Nope. They both target the exact same platform. There are coding issues that apply to one but not the other, but in the end, it's just a matter of preference.
For example, C# doesn't support optional parameters in method calls, where as VB.NET does. On the other hand, VB.NET doesn't support pointers and "unsafe" code, where as C# does.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
VB.Net and C# are arguably becomming more and more different over time (Will the idea of a '.Net developer' soon die?[^].
In my opinion, each language has their own unique features that allow you to solve problems in different ways programmatically. One language might have a particular feature that will allow you to solve a problem in a more elegant way, or in a way that requires less time.
However, I'd argue that for many projects the differences are insignificant. In terms of meeting a user's requirements or coding out an object model from a class diagram, there's nothing VB.Net does that C# can't, and vice-versa. In this case, the decision might have more to do with developer skills and which language the developer(s) is(are) more comfortable with.
Michael Hodnick
www.kindohm.com
|
|
|
|
|
Mike Hodnick wrote:
there's nothing VB.Net does that C# can't, and vice-versa.
Whoa! Don't let Christian see you posting this! 
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Mike Hodnick wrote:
VB.Net and C# are arguably becomming more and more different over time
That would not surprise me. Redmond has probably heard a lot of whining from C# developers to the effect of:
"When we used C++ we never had to bother with developing a good user interface, since that was basically impossible, and so we had that extra time to bash VB developers instead. Now not only are we expected to create decent GUI's, but we really can't whine about VB anymore. Why can't you make C# 'better' so we can get back to the good 'ol days?"
And they are probably concerned that Sun is telling all the Java developers "C# may look like Java, but it's really just VB."
:->
|
|
|
|
|
Hi!!
i'm opening a pdf document using vb.net. I'm using this simple code:
Public Class PdfAutomation
Public WithEvents wxProcess As New Process
Public Sub OpenPdfVisible(ByVal sPath As String)
Try
wxProcess.StartInfo.FileName = sPath
wxProcess.Start()
wxProcess.EnableRaisingEvents = True
Catch ex As Exception
MsgBox(ex.Message)
End Try
End Sub
The problem is when i want to close the document. If i have more than one pdf document open they will close all the documents. The pdf .exe only creates one process to open all the documents.
I tryed to create an object like :Pdfapp = CreateObject("pdf.Application") when i open the pdf but it's not possible. I received a message:"Cannot create ActiveX component"...
Anyone can help me? Its' urgent.
Bruno Costa
|
|
|
|
|
Instead of "pdf.Application", I think you're looking for "pdf.pdfctrl.1". I haven't tried it though.
You might even have better luck using the Adobe Acrobat SDK[^].
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I've written a short procedure intended to "watch" for changes to a specific file's time stamp. I've tried FileSystemWatcher.NotifyFilter.LastAccess and it only reads changes to Date, not Time.
This code is very cumbersome, inelegant mostly due to the DO . . LOOP which runs constantly.
Is there a simpler, cleaner way to do the same thing?
Imports System
Imports System.IO
Public Class Watcher
Public Shared Sub Main()
Dim filepath As String = "C:\Documents and Settings\ballcx\My Documents\My Music\tada.wav"
File.SetLastAccessTime(filepath, New DateTime(1985, 5, 4, 0, 0, 0))
Dim ot As DateTime = File.GetLastAccessTime(filepath)
Dim nt As DateTime = File.GetLastAccessTime(filepath)
Dim Ctr As Integer = 0
Dim diff As TimeSpan
Dim diff_min As Integer
' Begin watching.
Do While ot <> #12:00:00 AM#
nt = File.GetLastAccessTime(filepath)
If nt <> ot Then
diff = nt.Subtract(ot)
diff_min = diff.Minutes
If diff_min > 2 Then MsgBox(nt)
ot = nt
End If
Loop
End Sub
|
|
|
|
|
The FileSystemWatcher DOES watch on the LastAccess time the file. The problem is that NTFS, for performance reasons, will delay updating the last access TIME for up to an hour!
See Setting and Getting the Timestamp of a File[^] in the Platform SDK for a little more information on the resolutions of the file times.
You might want to use LastWrite instead. LastAccess will also change if the user just right-clicks a file and gets the Properties page on it, so that might not be a good choice to monitor for.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I have inherited the maintenance of a VB6 program that uses two DLLs, for which I don't have the source, and would very much like to convert this app, for which I do have the source, to VB.NET.
Please tell me how to get around the two DLLs problem.
Regards,
Alf Stockton
-- modified at 11:51 Wednesday 28th September, 2005
|
|
|
|
|
You'll most likely use them in VB.NET the same way the VB6 code uses them. If your code is using Declare statements, you'll do the same thing in VB.NET. If your .DLL's are COM-based, you'll be setting references to them, just like in VB6.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Are you suggesting that the Dlls do not need to be rebuilt and can just be called as they currently are ?
As a matter of interest the one is the driver for a mag stripe card reader and the other is the driver for a thermal printer.
Regards,
Alf Stockton
|
|
|
|
|
StrayGrey wrote:
Are you suggesting that the Dlls do not need to be rebuilt and can just be called as they currently are ?
Yep. Whatever way your VB6 code is accessing the .DLL functions now, the VB.NET code will be using the same methods.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
