|
Hi,
I have a program converted to VB.NET 2005 from VB6.
I uses control arrays extensively.
I am having a problem the the dtpicker control (AxMSComCtl2.AxPickter)
I frequently get 'not legal oledate' and other errors when accessing the control (reading or writing). We have controls just for short date and time i.e.
dtpFromLast and dtpFromLastTime
using
s = cstr(frm.dtpFromLast).value
or _value
or
frm.dtpFromLast.value = today
or
frm.dtpFromLast.time = now
Sometimes it works sometimes not.
The form in question is not always in focus and may not be visible (sometimes fails even when visible). It is a settings screen and not the screen where the work is being done.
Please just do not tell me to use another control as the windows date time control without some background explanation.
Thanks
modified on Monday, May 17, 2010 3:32 PM
|
|
|
|
|
By the sound of it, you are using a third party date time picker, are you, or is AxMSComCtl2.AxPickter simply what you named it?
If it is .Net's regular DateTimePicker control. Without seeing more specific code, I would guess the problem can be found in the conversion from a date value to a string value and back. Especially converting a string to a date value is always risky.
You could try the following things:
1. enclose the relevant code in Try Catch blocks with MsgBox(ex.ToString), and/or set a break point and walk through the code line by line, to see what value is actually being passed to whatever it is that is expecting a datetime value. You may see yyyy/MM/dd in your GUI, but the code may try to pass yyyy/dd/MM (for example)
2. do not use cstr(frm.dtpFromLast.value), but rather frm.dtpFromLast.value.ToShortDate.
3. look into IFormatProvider. (Example: Public Finn As IFormatProvider = New Globalization.CultureInfo("fi-FI")). Your Windows regional settings determine the format of the date in your dtp control (yyyy/MM/dd or dd-MM-yyyy or yyyy/dd/MM, etc.). When you convert it to string, and then back to a date, it may not necessarily translate correctly.
4. "oledate" suggests that this app is sending these dates to a database. Databases are notoriously sensitive to all kinds of date format problems. You may have to check what format your database is expecting, and form your date accordingly. Also sticking with pure datetime values, instead of converting to string and back, will prevent a lot, if not all, of your problems.
5. If you insist on converting dates to strings and back, use frm.dtpFromLast.value.ToShortDate and cDate(frm.dtpFromLast.value.ToShortDate).Date
My advice is free, and you may get what you paid for.
|
|
|
|
|
Thanks Johan
It is NOT a 3rd party control. It is in VB.NET 2005. Part of VB6 compatibility I believe.
The tostring will not work. I have tried that in Immediate mode.
These settings are written to a file which is why strings a being used.
The control is not linked to a database.
Since the code sometimes works sometimes not putting the code in would not be very helpful but here is some that fails.
With frmWebDownLoad
.dtpFromLastTime(0)._Value = CDate(Ss)
or
.dtpFromLastTime(0).Value = CDate(Ss)
end with
.
.
.
frmWebDownLoad.dtpFromLast(ThisStoreNdx)._Value = Today
Even doing a Add Watch shows has it Not a legal date in the watch window.
We are in the US so using mm/dd/yyyy.
But the problem occurs on the time control .dtpFromLastTime(0) (Format=Time) also when doing
.dtpFromLastTime(0).Value = cdate("00:00:00")
I believe it has more to do with the form that it is in and the form life cycle but just don't have enough to go on.
And it does not always fail.
I will try to get more info.
|
|
|
|
|
Everything you have told me so far (also in your additional post), makes me suspect something. In old VB6 cross form actions were simple, but .NET uses threads in a totally different way. Am I correct in my suspicion that the Ss string has been declared in either form's code ? If so, you could try the Global module method. In other words, add a module to your project and move the Ss string (and all other similar ones) here, and remember to make it Public.
Also, again, as this error only happens some of the time, I suggest that you put your code in a Try Catch block, with MsgBox(Ss) in the Catch. Then try to recreate the problem by testing with ambiguous dates like for example 10/13/2009. And, again, look into cultureinfo, it will solve a lot of headaches with things like PM and AM and such. This link[^] will come in handy.
Another method to ensure correct values, which takes a little more coding, is to use the dtpFromLastTime.Value.Day / .Month / .Year / .Minutes / .etc properties. With these you can more securely parse the date into the string for your settings.
As for the time issue, I seem to remember having had similar problems once. I found that adding a date (any date) solved it all, as sometimes, for reasons unknown to me, a string like "00:00:00" will get parsed into an impossible date instead of into a time.
Finally, if you need to save settings in a Windows forms app, I warmly suggest to switch to .NET's built in settings handling. They are laughably easy to use (see this article[^] on how easy. Added bonus, you can actually save dates, fonts, colors, and pretty much all other types, instead of only strings.
My advice is free, and you may get what you paid for.
|
|
|
|
|
Ss is a local variable (Dim Ss as string)
But I do not understand your point. Why would having Ss be a public variable make any difference. I would believe it has something more with the forms and that if it goes through form.terminating (and we do a c.cancel=true:hide) it fails but a plan hide does not.
EACH function or sub has a Dim Ss as string. These are work strings that are used and cannot be made global.
Again, "00:00:00" sometimes works sometimes not depending on the 'state' of the form in which the dtPicker is located.
Changing to the .Net settings handling would be a major change.
The program has about 15 forms and 20 modules with hundreds of functions and subs. Each form has entries in an ini file that are in exact relations to a control on the form. 1 ReadIni and 1 SaveIni work for all the forms.
|
|
|
|
|
QBTeKcom wrote: These are work strings that are used and cannot be made global
Yes they can, and they should be.
This e.Cancel, hide trick you are using is bad news. I am surprised that you are not being flooded with all kinds of errors, sending values directly from form to form.
Trust me, you can either pull out your hair for the remainder of this project, or spend one or two hours to bring this old vb6 code a little bit up to .net standards.
Create a global module, move all your Ss strings there, renaming them of course to something like Ss_Form1, Ss_Form2, etc. Then when a date is altered on a form, store this value in the relevant public string, and just let the form be closed after that. If nothing else, you are really putting a burden on memory, by keeping a whole form alive, just to make sure that a single value can be accessed from elsewhere. If you have any other such variables that are used across forms, I warmly recommend moving them to the same global module as well.
As for porting the settings system from an ini file to .net's setting solution, .net uses an xml file to store all settings, and you can even determine the type (string, integer, date, etc). These settings are then directly available in the intellisense of your editor (My.Settings.SomeSettingName). This will speed up future development, and cut down on lines of code looking for the correct text in the ini file, and validating / parsing it.
Just as a suggestion, you could create a single dummy setting, then take a look at the xml file (it will be called app.config in your project explorer tree), and just write a little program to convert the ini file to an xml one (you might even be able to do it quick and dirty with Excel).
My advice is free, and you may get what you paid for.
|
|
|
|
|
This would take much more that a few hours and I do not believe that changing a local variable to a global would make any difference on the dtPicker control since if fails even when just accessing it as below where variab IS a global variable
variab = .dtpFromLast(ThisStoreNdx).value
The FromClosing may be at fault but don't know why. I did not want the FromLoad to be executed again but that is a more easier test than changing the HUNDREDs (218 for a quick count)of Dim Ss in EACH function and sub in the program.
I am familar with the settings and xml file. This also would take a long time to implement and I do not think it has anything to do with the problem.
I am going to create a test project with just 2 forms and no real code except accessing the dtPickers, etc to see the behavior.
|
|
|
|
|
QBTeKcom wrote: variab = .dtpFromLast(ThisStoreNdx).value
But where does this take place, in the form that owns the .dtpFromLast(ThisStoreNdx) control or elsewhere?
QBTeKcom wrote: changing the HUNDREDs (218 for a quick count)of Dim Ss in EACH function and sub in the program
You will have only one global Ss variable per form. You can use Excel to create the needed variables inside a minute and per form you can just use the editor's replace all function. Or do you have hundreds of forms?
QBTeKcom wrote: I am going to create a test project with just 2 forms and no real code except accessing the dtPickers, etc to see the behavior
That is an excellent idea. Then if you experience the same issue, you can easily test my suggestion with the global module. Otherwise there may be a problem with the automatically upgraded code, and then you are really screwed (so fingers crossed).
My advice is free, and you may get what you paid for.
|
|
|
|
|
This is all now from the test project.
variab = .dtpFromLast(ThisStoreNdx).value
is in a function in Module1.vb
It seems that the dtPicker control operates different than the other controls.
The use of Ss is as a local and making is a global on the form would require a change in the code. If I move Ss to the top for the form and then take out all the Dim Ss's each function would have to be changed since the local is now 1 variable to the form.
Function One
Dim Ss as string
.
.
Ss = "123"
if Not Funct(parm:=ss) then
endif
.
.
End Function
Function Funct(pS as string) as boolean
Dim Ss as string
Ss = Ps
.
.
end Function
|
|
|
|
|
Did some more testing. This time getting
35788 hex(8BCC) An error occurred in a call to the Windows Date and Time Picker control
This is related somehow to the state of the form.
In this test the test code is on a control on the main form while the dtPickter was on another.
? ss
"8:03:51 PM"
"Update Last Fields failed to update From last Time (8:03:51 PM) 35788 hex(8BCC) An error occurred in a call to the Windows Date and Time Picker control."
But this works
FormWebDownload.dtpFromLastTime(ThisStoreNdx).text = Ss
This error occurs if you open FormWebDownload then x it out. Our form closing sub will do a e.cancel=true, hide. It come right back into the form closing sub.
The the error occurs.
If we do not use the X but use a control button on FormWebDownload which just does a hide it works fine.
If the form is not shown. It seems to work fine. Just something about the x'ing it out.
Can't seem to be able to re-create the oledate problem today.
|
|
|
|
|
Ok the Not a legal OleAut date. came back on
With frmWebDownload
WhereAT = "DOOGSP, Last Order Date " & CStr(.dtpFromLast(ThisStoreNdx).Value)
errors above
but then I put it in an Add watch first the _value in the watch is Not a legal OleAut date then it changes to a valid date???????
This is NOT running in the code behind the form.
HELP!!!! I am going nuts!!!!!
It fails if I open the form and then close it but as soon as I do a watch on it it works.
What is the formclosing hide e.cancel = true:hide doing and why does the watch make it work????
modified on Wednesday, May 19, 2010 4:57 PM
|
|
|
|
|
Ok, I have recreated the problem on a small test project. Just 2 forms and 1 module.
The Not a legal OleAut Date did come up on
sJunk = Form2.dtpFrom(i).Value
from form1
(sJunk is a global string in the module) Happens as a local variable also.
The problem seems to ONLY occur if form2.ShowDialog is not not when it is just form2.show.
It has nothing to do with the form2 formclosing. Fails with or without it.
So it seems that there is a big difference between show and showDialog as far as the controls on the form.
Also when the formclosing was there the show only went through the closing once while the showDialog twice. Don't know why.
I have put in form2.dtpFromTime(0) in the add watch and after a ShowDialog then with a button on form2 to hide the watch shows _Value ("Not a legal OleAut date") but Value has a valid date #5/20/1020 7:53:50 AM# (date).
Failing on Ss = Form2.dtpFromTime(i).Value
s is a local string and i is a local integer =0
So why the difference between _value and value and between dtpFrom and dtpFromTime (dtpFromTime is format time)???
|
|
|
|
|
Here is module1.
Option Strict Off
Option Explicit On
Module Module1
Public NIL As String = vbNullString
Public L As Integer
Public S4Junk, S2Junk, SssJunk, sJunk, SsJunk, S1Junk, S3Junk, S5Junk As String
Public gForm1 As Form1 = Form1
Public gForm2 As Form2 = Form2
Public Ern As Integer, Erd As String = NIL, Msg As String
Public Function Test() As Boolean
Dim i As Short
Dim s As String = NIL, Ss As String = NIL, Sss As String = NIL, S1 As String = NIL, S2 As String = NIL
On Error GoTo ErrX
s = gForm2.TextBox1.Text
Ss = gForm2.txtFromOrder(0).Text
Sss = gForm2.txtFromOrder(1).Text
S1 = gForm2.DateTimePicker1.Value
s = Form1.dtpFrom(i).Value
Ss = Form1.dtpFromTime(i).Value
'S1 = Form2.dtpFrom(i).Value
'Form2.Visible = True
If Not Form2.Logical_Form_Load Then ' 35788 if not visible
i = i
End If
s = gForm2.dtpFromTime(i)._Value ' OleAut not a legal date if ShowDialog
s = gForm2.dtpFromTime(i).Value
s = gForm2.dtpFrom(i)._Value
s = gForm2.dtpFrom(i).Value
S1 = Form2.dtpFromTime(i).Value
S2 = Form2.dtpFromTime(i)._Value
Return True
ErrX:
' With Logical 35788 An error occurred in a call to the Windows Date and Time Picker control
Ern = Err.Number : Erd = Err.Description
Stop
'Resume Next
Resume
Return False
End Function
End Module
|
|
|
|
|
I now have a better understanding of the behavior and a workaround but still do not understand why.
1. Seem to be limited to the dtPicker control from VB6 and not other ctls as DateTimePicker, textboxes, etc.
2. OleAut is not a legal date occurs in the same form code behind and err 35788 An error occurred in a call to the Windows Date and Time Picker control when in a different module.
3. Occurs when the form is NOT VISIBLE
4. FormClosing has no effect even though it is still not clear why it is invoked twice when it is Xed out.
5. Finally a workaround.
b=form2.visible:form2.visible=true:form2.visible=b
seems to fix the problem at least in the test project on VB.Net 2005.
Long term replacement of the VB6 dtPicker with .net DateTimePicker and a collection seems to be a way to go.
The workaround will be applied to our production program and we will see. We will be moving to either VB 2008 or 2010 shortly and not sure if the behaviour changes or not.
It would be nice to have explanation of what is happening.
|
|
|
|
|
Hi all
I need to work on databases that have .db extension.
My boss insists that this type of database is the fastest.
i tried searching for it and found that its a thumbnail database on filext.com
I need to put text on the database and am sure its possible.
and on googling I found several links for java,etc.
I don't know nothing about .db files but I know how to handle ADO.NET
Help me with some info about them like its source website,etc (any info is welcome)
Thanks
|
|
|
|
|
Just because it has a .db extension doesn't mean to say that the database type (e.g. ms-sql, mysql, dbase) is the one you think it is.
Your boss needs to tell you what the exact type is, and what version it is.
From here you can find the correct api libraries and connectors etc, that you will need for interacting with the database
|
|
|
|
|
|
thanks for the reply.
My boss says that it should has the extension of .db
Thats the only matter with him.
He's a jerk.
I will now give an overview of my (strictly my boss')
the database extension should be .db (I dunno why he's sticking with that)
only one table is required.
the application should run on any windows with .net 3.5 (he calls that portable)
the read/write speed should be fast.
that's all.
|
|
|
|
|
Jack_18 wrote: He's a jerk.
And thats a good way to get fired!
|
|
|
|
|
He knows me by another name.
anyway I don't think he visits the coding forums! 
|
|
|
|
|
Since your boss wants to use .db files, and the database only has one table, it's up to you to decide on which database to use. It sounds like it's a light-weight database, and no concurrency is involved.
If that is the case, I suggest that you use SQLite. The database file used by SQLite can be named using any extension, so you just use .db.
SQLite is fast, so your boss will be happy.
If you use C/C++, you can use the source code of SQLite directly in your program. For C++ there are a few wrappers available that greatly simplify the use of SQLite.
If you use C#/VB.NET, then ADO.NET implementations are available, making it very easy to use.
|
|
|
|
|
hey thanks buddy!
will that be portable?
the exe file should run without the need of any dlls.
|
|
|
|
|
I performed some search and found that you need "sqlite.dll" in the same folder as the exe file.
I know its only 441 KB in size but its my boss. He's mad.
can you give me any other choices?
|
|
|
|
|
There are no other choices. Any database you use with it's own provider is going to a) provide the best performance and b) require the use of a library (.DLL's) to do it.
|
|
|
|
|
(VB.NET) I am using 2 DateTimepicker controls on form one for To: and 2nd for From (TO get particular Range of DATE)
Now i want to check all dates(TO->from)Range from db which are in range. Plz tell me the Query and should i use db column type as DateTime now i m using ntext to save date .
I m using sqlserver2005
plz help
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
