Using Microsoft access, visual basic.
I'm having a big problem doing this task.
What I have done: Created a table on access where I have put measurements in (from meters):
mile = 10000meters, nautic mile = 1862meters, English mile=1652, kilometers = 1000 meters and all the way down to Millimeters.
What I have created for input:
1 box takes an Integer to be converted and a 1 box specified with an initial unit.
What I have created for Output:
1 box shows the Integer of result with 1 box specified the chosen unit of the output.
Can anyone please, please help me with the codes?
Honestly I'd never really noticed the CONVERT function until today but here's a quick demo of how I'd slap together a "conversion tool" in Excel.
If you want to do the same thing in Access, the premise is the same, but it will be a bit more work since you'll have to design the form from scratch instead of using a worksheet, which is kind of meant for this kind of job.
Using Excel functions in Access
Before you are able to use Excel's CONVERT function in Access, you'll need to reference the Microsoft Excel Object Library.
In Access, open any VBA Module.
GoTools > References
Check the box next to Microsoft Excel 16.0 Object Library. (The version number will vary if you have an older version of Office.)
Then you can call most Excel functions from Access VBA or queries with WorksheetFunction (the same way you would use them in Excel VBA).
For example:
MsgBox WorksheetFunction.Convert(3.7, "m", "ft")
...displays a message box with the number of feet in 3.7 metres.
The calculations will be the easy part; a couple lines of VBA in the On Change or On Exit events will trigger the calculation.
The most time-consuming part will likely be perfecting the placement and formatting of the controls on the form, which is by no means difficult (and there are several tutorials online that can provide the basics if necessary.)
Lastly, keep in mind that there are no doubt a plethora of existing conversion tools available for free download with a little Googling... (I'm confident that you're not the first person who wanted to use MS Office to convert measurements.) 😉
More Information:
Microsoft Docs : WorksheetFunction.Convert Method
Microsoft Docs : List of Worksheet Functions Available to Visual Basic
Office Support : Create a form in Access
QuackIt: Microsoft Access Tutorial
Blueclaw : Access Event Procedures
You can download the demo xlsx used above from JumpShare here.
For both comboboxes, bind them to column 2, faktorTilMeter, and set the ColumnWidths to, say: 2,542cm;0cm.
Then, assign this expression as ControlSource for your output textbox:
=TextboxInput/ComboboxFrom*ComboboxTo
Related
I am trying to automate a repetitive task in the SAP GUI. I need to search for an order number, select the row that the order number is in and then click a button to complete the task. I have recorded a macro which gives me:
session.findById("wnd[0]").maximize
session.findById("wnd[0]/usr/cntlCONTAINER/shellcont/shell").pressToolbarButton "&FIND"
session.findById("wnd[1]/usr/txtGS_SEARCH-VALUE").text = "4521305207"
session.findById("wnd[1]/usr/txtGS_SEARCH-VALUE").caretPosition = 10
session.findById("wnd[1]/tbar[0]/btn[0]").press
session.findById("wnd[1]/tbar[0]/btn[12]").press
session.findById("wnd[0]/usr/cntlCONTAINER/shellcont/shell").currentCellColumn = ""
session.findById("wnd[0]/usr/cntlCONTAINER/shellcont/shell").selectedRows = "2894"
session.findById("wnd[0]/tbar[1]/btn[14]").press
session.findById("wnd[1]/usr/chk[1,6]").selected = true
The line:
session.findById("wnd[1]/usr/txtGS_SEARCH-VALUE").text = "4521305207"
Corresponds to the order I want to search, but if I change this value it still tries to process the same order that the macro was recorded on, I'm assuming because of the line:
session.findById("wnd[0]/usr/cntlCONTAINER/shellcont/shell").selectedRows = "2894"
Does anyone know how I would go about finding the number of the row which corresponds to the outcome of the SEARCH-VALUE and then using that as the .selectedRows = ""?
First of all I'd really recommend you add a reference to the native SAP library. Go to your VBA Editor, click Tools, then References, then Browse, and find this file: "C:\Program Files\SAP\FrontEnd\SAPgui\sapfewse.ocx". Add it, and now you'll have types and libraries and coding for SAP will be a lot easier, safer, and slightly faster (Variant types in VBA impose a tiny overhead that in this case is totally unnecessary). Get familiar with this new library if you are going to do any SAP scripting more than once.
Second, about this problem, what you have is a shell, of type GuiShell, which inherits from GuiGridView. GuiGridView looks like a table, a classic Excel-like set of rows and columns. In your transaction, is showing you a big list of orders, in which you go click the "Find" button, put the order you're looking for, and then close the Search Window. Back to your (Grid)Shell, this cell has been selected (Grid has properties SelectedCells, SelectedRows, SelectedColumns that get all set when you go find something), but then you go and modify the value of SelectedRows to a specific one.
So yeah, upon find, a cell has been selected, so all you need is to query its row and then assign it where you need:
Dim numrRow As Long
numrRow = session.FindById("wnd[0]/usr/cntlGRID1/shellcont/shell").CurrentCellRow
session.FindById("wnd[0]/usr/cntlGRID1/shellcont/shell").SelectedRows = numrRow
where "thisShell" is however you do to find a reference to the Shell (session.findByID("blabla") for example, but I'd advise to reduce all the findByID's, they're very slow and type-unsafe).
If you need help about this SAP libraries, feel free to maybe make some new post and ping me on the comments about it.
Our current work project involves opening a Microsoft PowerPoint file (.pptx format), changing some text and chart values, and then presenting the edited version to the end user.
This works rather well so far, but I'm puzzled by what happens when I try to validate the document afterwards. Using the DocumentFormat.OpenXml.Validation.OpenXmlValidator class, I run the Validate function with the PresentationDocument passed in as the only parameter.
Dim document As PresentationDocument = PresentationDocument.Open(templateFilePath, True)
Dim validator As OpenXmlValidator = New OpenXmlValidator()
Dim errors = validator.Validate(document)
For Each errInfo As ValidationErrorInfo In errors
Debug.Print("Error: """ & errInfo .Description & """")
Debug.Print("XPath: " & errInfo .Path.XPath)
Next
Validate() returns an array filled with instances of ValidationErrorInfo. Just about all of these give the same error description when debugging:
The 'smtClean' attribute is not declared.
The XPath for each error looks like this (numbers vary; there appears to be one error per piece of text):
/p:sldLayout[1]/p:cSld[1]/p:spTree[1]/p:sp[4]/p:txBody[1]/a:p[1]/a:fld[1]/a:rPr[1]
Every TableCell has a Paragraph, with child element Run, and this Run has child elements RunProperties and Text. I modify the Text in my scripts, but I do not touch anything else.
Searching for 'smtClean' gave me an MSDN entry for RunProperties which shows 'smtClean' as one of the possible values to be set, but if I create a new instance of DocumentFormat.OpenXml.Presentation.Drawing.RunProperties the 'smtClean' attribute is not available.
Looking around, I found threads where people mentioned merged documents to be one possible cause, but these errors occur even in an unmodified presentation with only a single slide and table in it. Using the Open XML SDK 2.5 Productivity Tool to Validate the base document, I get the same result.
The errors also occur no matter which format I ask the Validator to test for - both the 2007, 2010 and 2013 version of the PowerPoint format return the same amount of errors.
Finally: The file itself works just fine in PowerPoint, even after being modified. I am curious about why the validator returns so many errors, however.
Thanks in advance for any help.
we process Office Documents and remove this Attribute in all Types (Word, Powerpoint, Excel) without Side-Effects. Eric White has identified this as Bug: smtpClean attribute not supported
It is fixed in the current OpenXml SDK on Branch Office2016: https://github.com/OfficeDev/Open-XML-SDK/tree/Office2016
Regards...
Smart tags were deprecated in Office 2010, and the SDK v2.5 validator doesn't support smart tag elements and therefore marks them as invalid.
Please see this MSDN article for more information.
The current developer of the productivity tool says in this thread that the smtClean validation error was a bug in some situations and has been fixed in v3 of the tool.
v3 (the Office 2016 productivity tool) can be found here, however I'm not sure how compatible it is with older versions of Office.
Evening,
I'm bashing my head against a wall with the following problem:
I'm loading numbers from cells from a Number column with size=16
and decimal places = 2 inside adBase III .dbf file.
These numbers, when viewed with a DbfViewer appear as: 12345.12, where there is no thousands separator and the decimal
separator is ..
I parse the number from the cell in the database using decimal.parse(val).
I do stuff with that number.
I am using the ClosedXML library to paste the number into an .xlsx Excel file cell with the following formula: "=R[-1]C * 100/" & val where val is the value I obtained from the dBaseIII database file. This is done with the following statements:
Dim formula as String = "=R[-1]C * 100/" & project.TotalIncome(i)
cell.FormulaR1C1 = formula.
I am using two programming environments:
A Windows 8.1 machine with Visual Studio 2013 Community and Office 2010.
A Windows 8.1 machine with Visual Studio 2013 Ultimate and Office 2013.
I have made sure that both environments have the same Language, Date, Time and Number format, both for Windows and Office.
When I build and execute the program from the Option 1 Environment, everything pastes fine inside the Excel file. I navigate to the cell containing the formula, and whether or not the value obtained had decimal places, the formula is there.
However, If I build and execute the program from the Option 2 Environment, I get a:
Removed Records: Formula from /xl/worksheets/sheet.xml part
Removed Records: Formula from /xl/calcChain.xml part (calculation properties)
I tried adding a breakpoint in Environment 2, opening the Locals window and editing those values which had decimal places and everything worked as intended, whereas when I use Environment 1 I have no trouble whatsoever when the value has decimal places.
I have tried the following (in Environment 2):
Dim nfi As NumberFormatInfo = New CultureInfo("es-ES", False).NumberFormat
nfi.NumberDecimalSeparator = ","
value = Decimal.Parse(row("VALUECOL"), nfi)
also:
value = Decimal.Parse(row("VALUECOL"), New CultureInfo("es-ES"))
To no avail.
I have opened the XML file containing the Excel Sheet info in Environment 2 and found this:
<x:c r="L101" s="41">
<x:f>L100 * 100/57125,71</x:f>
</x:c>
Whereas the definitions for the same XML file created by the Environment 1 has the following cell value:
<x:c r="L101" s="41">
<x:f>L100 * 100/57125.71</x:f>
</x:c>
So, is it a Visual Studio Locale thing (which both have the same, as far as I can see), or am I missing something else?
EDIT: Printing out the current Locale with:
Console.WriteLine(CultureInfo.CurrentCulture.Name)
yields the same es-ES on both Environment 1 and Environment 2.
EDIT 2:
Taken from: Microsoft Office XML formats. Defective by design.
To save them time, Microsoft chose to store XML using the US English
locale regardless of all settings above. [...]
Also, for Excel formulas, it means the formula names are US English
formula names, [...] it implies you are willing to work with US English
function names (plus US English separators, ...).
So basically it all boils down (I believe) to a pre localisation of the decimal value into the Excel XML taking into account something, somewhere.
In Environment 2, any other (non-formula) value I write to the Excel file appears in the XML as an en-US localised value (i.e. 12345.12). Most of them brought in by a dataTable import. However, since writing a formula requires the input of a string, and Visual Studio applies locale settings to said string, it ends up as 12345,12 in the Excel XML, which results in the previously mentioned errors.
So, what on earth is Visual Studio taking from Environment 1 that is different from Environment 2? All possible UI localisation options are exactly the same in both machines...
I had a similar issue before, and found that there was a different dll file in my project references. The dll's were named the same, I only noticed because of a file size difference. Once I manually linked to the same one on both Dev machines, I got the expected results.
Like I said, my issue was different... But it did also involve excel files, and I did have Excel 2010 on one Dev machine and 2013 on the other.
I don't even know if this qualifies as an answer since I still have no clue about where's the localisation variable that Environment 1 has different from Environment 2.
However, It seems Visual Studio -when using different localisations- deals internally with de-localised decimal variables, but with localised string variables. Even when checking the locals panel during debugging, the value of a decimal number stored in a dictionary entry will appear as its localised version on the keyValuePair entry, and as a de-localised en-US value when expanded:
Hence, when outputting a dataTable as a whole to the Excel file, it's written onto the XML as en-US values. On the other hand, when outputting a formula (a.k.a. a string) it pours over the localised version of the associated decimal value.
Conclusion: When dealing with Office files in localised systems, just write the data as de-localised (i.e. en-US) and let the software localise it for you.
Ended up doing the following dirty patch:
Dim formula As String = "=R[-1]C * 100/" & project.TotalIncome(i).ToString().Replace(",", ".")
I have a report that needs to process the data that it get from SQL before show it.
For that, I have a custom code, and a Dictionary where I push all the processed data.
My problem is that if I save the dictionary in a report variable when I export the report to Word that variable seems to be cleaned.
What is the lifecycle of the reports variables? What is the most convenient way of saving an object during the report life.
Thanks!
I have been playing around with custom code for a about 6 weeks so I can answer some parts of the question of variable lifecycle in SSRS 2008 R2.
I have report that uses a Dictionary to store totals, allows me provide some specialist subtotals for financial stuff. I have something you can check (as I can't yet comment on things).
Have you declared the variable as 'shared', this is a custom code specific keyword that doesn't translate into VB.net. It ensures the variable lives to the next page, I tested this to Excel and word seemed to work fine transferring over the variable's data.
There is a trade off however under SSRS "report on demand" engine (on web, but not on BIDS) it holds the variable and doesn't garbage collect until the cache itself is cleared. I wrote some more custom code to indicate when my parameters changed and clears the variable.
Code;
Public Shared Dim Totals As New System.Collections.Generic.Dictionary(Of String, Decimal)
Public Function WipeKeys() as Decimal 'Clear Data from Dictionary (this will clear the cached object as well)
Totals.Clear()
Return 0D
End Function
I will also to recommend overwrite the key where ever possible to ensure reduction of addition loops.
Regards,
Hi there im having issues trying to transfer data from an excel spreadsheet to visual basic in the form of an array,any one know any reasonable means of doing so.I have searched online extensively but still cannot find a good tutorial on how to code it.
Simple step by step instructions with explanations would be appreciated as while im familiar with some parts of object orientated programming,I have never transferred data in this way.
Eventually I want to transfer this data onto an object orientated table with a few added buttons and functions thrown in
Cheers for any help guys
The easiest way would be to customise the following code:
examplerange = workbooks("Workbook 1").worksheets("Sheet 1").range("A1:B17")
where Workbook 1 is the name of the workbook that you are using (minus the extension, e.g. '.xlsx'), Sheet 1 is the name of the worksheet the range is located and A1:B17 is the range in which you wish to import.
This creates a Variant array-which is inefficient-however this is an easy way to import data into VBA and acceptable if you are not working with large sets of data.
Once you're more familiar, you'll be able to separate the elements in the code above and iterate through dynamic ranges as well as being able to import string / integer / boolean arrays to reduce memory usage.
Hope this is what you're looking for.