Dim fontsize As Single = CSng(SynopsisTSCmbFontSize.Text)
rtbSynopsis.Font = New Font(SynopsisTSCmbFonts.Text, fontsize)
to change the fontsize to the value selected in a combo box, the value has to be of the Single type.
the combobox is populated with numbers entered at the design mode, ranging from 7-78. I know that these are entered as strings.
the error is :
I have tried a number of things to convert the text (which are numbers, no letters) from the combobox to single to no avail. try parse did not work, trimming did not work, first convert to INT or DBL, then to SNG did not work.
What is the correct syntax here?
I would have thought that it was pretty standard stuff to change the fontsize.
I found a solution : instead of populating the combobox at design time, I populated it at runtime where I had full control over the type.
Dim i As Single
For i = 5 To 70
SynopsisTSCmbFontSize.Items.Add(i)
TreatmentTSCmbFontSize.Items.Add(i)
Next
once the comboboxes are correctly populated, I can run the rest of the code with no errors
thank you all for your time!
Alright. The goal is to programatically grab a string of numbers from an unbound control on a form. Why? I have a form that contains two controls for a start time and a finish time. The format for these controls are dd/mm/yyyy hh:dd. The end users are complaining that they hate having to take the time to enter the date and time in a single field, especially considering the old form (a horrible Excel spreadsheet where users could type whatever they felt like typing), allowed them to just type the 4-digit time. I am trying to replicate that experience, but as we know, date and time are wrapped into one field in Access.
The idea is to supply the date/time field with the values from the string using separate unbound control. For example, one control will be labelled 'Start Time' and will accept 4 numbers with an input mask of 99:99. Before the form is updated, I would like to pass the string from the control Unfortunately, I do not have the code, but I will attempt to build psuedo code here:
Class Level Module
Private Sub Form_BeforeUpdate(Cancel As Integer)
strStartTime as String
strFinishTime as String
strDate as String
rstDailyLog as recordset
Set rstDailylog = CurrentDb.OpenRecordset ("Daily Log" dbOpenDynaset)
'assign variables to unbound controls on form
strStartTime = Me![Start Time]
strFinishTime = Me![Finish Time]
'Here, I assume I begin parsing my string to the date/time field
'function to edit send the string to the actual date/time field
'Basically, copied from Microsoft Docs
Sub EditName(rstCovertString As Recordset, strStart As String, strFinish As String)
With rstConvertString
.Edit
![Start Time] = strStart
![Finish Time] = strFinish
.Update
.Bookmark = .LastModified
End With
What are the implications of doing so? For example, if the bound form displays a record with an unbound value, how will that record display the desired data?
As I was building this code, I just realized that the field that holds the date/time is a date/time data type?
Now I am really confused. If they are different data types, can I even send my start/finish variables to that control as a string?
It turns out that Access does a TRUCKLOAD of data type conversions for you.
When text box controls are bound to a underlying table, then that text box will return a datetime data type. Even if you stuff in a string - it gets converted to a datetime data type behind the scenes.
And same goes for text, or if the control is bound to a number. (again, data type forcing is actually occurring here. However, VBA is rather forgiving in this regards.
Thus, most of the time you don't notice this issue.
HOWEVER, WHEN the text box is NOT bound to a underlying table, then the data type of that text box is more loosely goosey.
So, set the format of the un-bound text box to date format. If you do this, then even assigning a string value to the text box will cause access to convert the string into a date time. In fact, your code should STILL take the data from that table, and if you are not directly assigining the date column to the text box?
Well, then format the string as USA format.
eg:
me.MyStartDate = format(dtValue, "MM/DD/YYYY")
or
me.MyStartDate = format(dtValue, "YYYY-MM-DD")
You will find that EVEN if your date format is different then above (say based on your computers regional settings), then Access will convert the above to an interal date format, and THEN display what your regional settings are REGARDLESS of the above.
So, your display might be:
DD/MM/YYYY (day first)
But, doing this:
me.MyStartDate = dtvalue
or
me.MyStartDate = format(dtValue,"YYYY-MM-DD")
will work.
So, do NOT convert the datetime value from the table into a string IF POSSIBLE to avoid doing so.
So, you simply assign that actual datetime value directly it to the text box. As long as Access sees and knows that text box has a date format, then it will assume and work with that text box as a date time data type.
The above ONLY works if you set the un-bound text box to have some kind of date formatting. Once you told access that the text box is a date type text box, then directly assign date values from a table (without conversion to a string) is your BEST solution.
As noted, for bound text boxes then the text box will take on the correct datatype - even if you don't format the text box.
And the same above trick also applies to number formats. And thus setting a number format for the text box will result in that text box NOT being a string/text type, but an actual number.
So, you can force/set un-bound text boxes to a given data type by use of the formatting option. Once you do this, then you should not need to format data from a table, but in fact just shove the actual date value into the text box. You can (and should) thus now be able to set any kind of date formatting you want for the text box - even setting that is the exact opposite of the actual date format your computer (and user) has chosen on a whim.
In other words, if you do this correct?
Then you don't care, or even have to know the date format settings on any given computer, and your code will always work.
Of all the suggestions here by me?
If possible, assign the actual date value to the text box, and do NOT format the string. This will allow you to set any kind of date/time format for the text box.
Once you defined/set the text box to be a date format, then it is a datetime thing and data type. As a result, you should not require any conversion from the table data to set/fill out the text box.
Edit
You have:
'assign variables to unbound controls on form
strStartTime = Me![Start Time]
strFinishTime = Me![Finish Time]
No! - declare the above two vars as date, not strings.
dim dtStartTime as date
dim dtFinishTime as date
now:
dtStartTime = Me![Start Time]
dtFinishTime = Me![Finish Time]
'Here, I assume I begin parsing my string to the date/time field
No, don't parse. You have the data as a internal datetime. How you display this data is up to you or the users regional settings. As a developer, it is a date type and a date "thing". Don't convert to string!!!
'function to edit send the string to the actual date/time field
'Basically, copied from Microsoft Docs
Sub EditName(rstCovertString As Dao.Recordset, dtStart As Date, _
dtFinish As date)
Access will often recognize a string with a date/time structure as a date/time value. Could use CDate() function to be sure or use # delimiters.
Do these tests in VBA editor immediate window.
?IsDate("1/1/2020 14:50")
?IsDate(CDate("1/1/2020 14:50"))
?IsDate(#1/1/2020 14:50#)
?IsDate("1/1/2020" & " " & "14:50")
All return True.
If you want to display the saved date/time then bind a textbox to the field. Lock the control if you don't want users to edit in it. Then use VBA to save any edits done in the unbound textboxes. I recommend AfterUpdate event for code to save. Use BeforeUpate event to validate user input.
I have an Excel dataset to be imported into Access. One of the fields in Excel has type General, but it's really numbers shown as text. And some of the data in this field is blank. So when importing into Access, I tried to convert this field to double, but due to having blanks in the data, it's giving me type conversion error. Is there a way to handle blanks as 0s and convert to double during the import steps?
Also I think there used to be an "Advanced" button during the import fields step in Access. Now I don't see that button anymore.
In my testing, the blank cells are not the issue, it is the cells that are individually formatted to display as text and do have data. Recommend fixing the spreadsheet. review:
Convert 'numbers as text' to numbers
I have a user input box where you type in a string, annoyingly this string looks like a date 00/00/0000 and excel reformats it as such.
When the value can't be a date ex. 18/19/4561 (month can't be 18 or 19) it displays it correctly.
But whenever it can be seen as a possible date it switches things around.
I've tried setting the value as a string rather than nothing but excel still changes it when putting it in the page.
When I try manually inputting it in the cell or equal the values from a manually entered cell it works fine.
But whenever I get it from the inputbox it messes with it. Even when I hard code the string to a variable (x = "05/06/4564") it switches things around.
How do I force excel to leave the string as is?
Prefix the value with a single apostrophe and Excel will interpret it as a string.
Eg '18/19/4561
Also, have you tried setting the cell format to Text
I am looking for logic that converts an incorrect user input to a correct integer input.
For example, a user might mistakenly type in letters within an integer input and the logic changes that input to the correct form(integer).
Any ideas?
If you want only numeric values, you can use a numeric control instead of textbox (NumericUpDown if I remember correctly). Otherwise, you can listen to the OnKeyDown or OnKeyPress event, "see" what's inside the argument (the key typed by the user) and eventually change its input. For instance, I'm in Italy and often users use . or , for decimal separator. So I translate dot to comma while the user types. Also, when a non-number is typed, I set e.Cancel to true so nothing is appended to the text displayed.
For typing errors, a BK tree is often used, in conjunction with Levenshtein Distance. Here is a good explanation on how this is applied.
Why would you correct incorrect input? You would want to prompt the user to re-enter the information correctly and tell them to enter an integer.