Code to determine place of apostrophe

[bknight]

You never suggested that I add or remove anything, I simply attempted to compile and it did not, the code will not run period, end of discussion.
Now after I added the end function it compiled and ran.
This is the code I have. Please submit any changes you fell are necessary.


ETA: my machine will not run commented code lines.

[ChrisGreaves]

You never suggested that I add or remove anything, I simply attempted to compile and it did not, the code will not run period, end of discussion.
Now after I added the end function it compiled and ran.
This is the code I have. Please submit any changes you fell are necessary.
ETA: my machine will not run commented code lines.

hello. The supplied code should compile clean if you load it right out of the text file I supplied a few posts ago.
If you modify the code and try to compile it all bets are off.
In my step (4) I suggested that you drag and de-comment three lines away from the foot of the function.

Untitled3.png

As you can see in this side-by side example, if the three lines are dragged outside and then decommented, you will end up with compilable and running code.
Note especially that the Function StrSplitAt header is perfectly aligned; no need to add or remove any lines of code at all. Step 4 says:-

Code: Select all

(4) You can drag the three (green) commented lines from the end of the function “dblApostrophe” until they are immediately below that functions END statement, then de-comment them using the de-comment tool in the toolbar 

Did you not understand that step?

As for not being able to run commented code lines, I don't doubt that at all. In all the languages that I have used and designed I have yet to meet a translator that will execute commented lines. That is why we have commented lines.

Do you understand why those three lines ARE commented in the function dblApostrophe?

I think that you are trying to do too much too quickly here. I remain confident that my nine-step process will work and will deliver code that works for you in any MSOffice application.
Until you, or someone else, runs through those nine steps as laid out and reports back, I do not want to spend time looking at modified steps. Let's use those steps and then proceed.

I think that if you read through my last three posts you will find that you are not answering my questions.
In particular in this post as you worked through my nine steps, did you check that your screen matched my screen shots as you went along?
If not I suggest that you compare your screens with mine and then report back
Cheers, Chris

[bknight]

You never suggested that I add or remove anything, I simply attempted to compile and it did not, the code will not run period, end of discussion.
Now after I added the end function it compiled and ran.
This is the code I have. Please submit any changes you fell are necessary.
ETA: my machine will not run commented code lines.

hello. The supplied code should compile clean if you load it right out of the text file I supplied a few posts ago.
If you modify the code and try to compile it all bets are off.
In my step (4) I suggested that you drag and de-comment three lines away from the foot of the function.
Untitled3.pngAs you can see in this side-by side example, if the three lines are dragged outside and then decommented, you will end up with compilable and running code.
Note especially that the Function StrSplitAt header is perfectly aligned; no need to add or remove any lines of code at all. Step 4 says:-

Code: Select all

(4) You can drag the three (green) commented lines from the end of the function “dblApostrophe” until they are immediately below that functions END statement, then de-comment them using the de-comment tool in the toolbar 

Did you not understand that step?

As for not being able to run commented code lines, I don't doubt that at all. In all the languages that I have used and designed I have yet to meet a translator that will execute commented lines. That is why we have commented lines.

Do you understand why those three lines ARE commented in the function dblApostrophe?

No I don't, why don't you just add them to then end of code and leave them uncommented.

I think that you are trying to do too much too quickly here. I remain confident that my nine-step process will work and will deliver code that works for you in any MSOffice application.
Until you, or someone else, runs through those nine steps as laid out and reports back, I do not want to spend time looking at modified steps. Let's use those steps and then proceed.

I think that if you read through my last three posts you will find that you are not answering my questions.
In particular in this post as you worked through my nine steps, did you check that your screen matched my screen shots as you went along?
If not I suggest that you compare your screens with mine and then report back
Cheers, Chris

Perhaps you didn't read my posts as I clearly posted twice the code sub/function that I currently had and asked for a correction. What you had as code does compile but doesn't do anything that I am aware of and yes, the Sub TESTdblApostrophe() is at the end with the 'Sub TESTstrSplitAt() all commented out. I don't remember deleting the comments, but I may have.
So, lets get over the water under the bridge. How does one enter what looks a sting and give to your code?

[DocAElstein]

...I shall wait for any other member of Eileen's Lounge to confirm that the steps I suggested will produce the results that I spoke of.

Hi,
Hope I don't confuse the situation any more: I did no more than follow exactly the nine steps. As I have no idea what is being done here, I am just an innocent bystander, with a lot of computers and Word versions.
I don’t really understand what anything here is about, - you know I am very slow to get the point.
But I followed the 9 steps from Chris from here (http://www.eileenslounge.com/viewtopic. ... 50#p303250 )

The only thing that makes no sense to me is … (3) Save your work at this time with Alt+F then S …. - If I do that from the VB Editor, nothing much happens. If I do that from the word document then it puts some strange line in

Otherwise, in Word 2003, 2007, 2010, 2013 on a few different computers I get what Chris said.
If I run Sub TESTdblApostrophe() nothing happens, or rather I notice nothing. I guess that is what is expected? – it does not error, so I expect it runs OK. In fact if I run in step mode it steps through.
So I think that means all is well, it appears to do what ever it is you are doing.

If I change the line as Chris suggested, (8), (9), then it do error , which I think is what it should, -it's what Chris suggested should happen.



So without having the foggiest idea what it is you are all playing with, I can at least say following CHris’s steps , all do as he suggests for me - produce the results that he spoke of. ( apart from … (3) Save your work at this time with Alt+F then S …. – I know lots of way to save, but that is a new one on me, and it don’t save anything when I try it. - Assuming that works for you guys then it may be because I have German Office and German Windows / German Computers/Keyboards - a few shortcut and other key things work a bit differently in the Fatherland )


Alan

[HansV]

In the Visual Basic Editor, Alt+F, S is the equivalent of File > Save <docname>.
So you don't have to switch to the main application (Word, Excel, ...) and back if you want to save the active document/workbook/... before testing some code that you just created/modified.

[DocAElstein]

OK, thanks. Doesn't work for me - could be the German thing. ( The way I tested is , first save in the conventional way. Then I made a small change. Did the Alt+F, S , then closed without saving. Re opened and the small change I had made was gone.)
In all my versions, Alt+F brings something up, the thing below, The "Fenster", so maybe that messes it up.

Not important though, not the main issue.
The important question is...... why don't they call it here Microsoft Fensters?

[HansV]

Perhaps it'd be Alt+D, S, for Datei > Speichern?

[HansV]

And how about Ctrl+S? Isn't that the universal keyboard shortcut for Save in any language?

[DocAElstein]

Perhaps it'd be Alt+D, S, for Datei > Speichern?

Ja, das hat es getan! I would have figured that out eventually in a day or ten I expect. Still doesn't answer the main question as to why I don't have Microsoft Fensters on my computers...
_.______________________

And how about Ctrl+S? ..

Yep, that one always works for me

[SpeakEasy]

>raised to build libraries

Excellent! In which case you are ready for the library version that works in all VBA hosts ... :-)

Code: Select all

Function Convert2Num(Optional Price As String) As Double
    With CreateObject("MSScriptControl.ScriptControl")
        .Language = "jscript"
        Convert2Num = .eval((Replace(Price, "'", "+") & "/32"))
    End With
End Function

[ChrisGreaves]

...I shall wait for any other member of Eileen's Lounge to confirm that the steps I suggested will produce the results that I spoke of.

But I followed the 9 steps from Chris from here (http://www.eileenslounge.com/viewtopic. ... 50#p303250 )
The only thing that makes no sense to me is … (3) Save your work at this time with Alt+F then S …. ... Otherwise, in Word 2003, 2007, 2010, 2013 on a few different computers I get what Chris said.

Hi Al, and thanks for the evaluation.
I see much discussion about "saving files" below. I asked for a File save at this point because we have just made a significant change, specifically, creating a module of text. It seems prudent to save the file at this point.
I shall discuss Alt+F,S in separate responses below.

If I run Sub TESTdblApostrophe() nothing happens, or rather I notice nothing. I guess that is what is expected? – it does not error, so I expect it runs OK.

Exactly right.
The procedure is self-testing, albeit in a very simple way.
Self-testing algorithms have been around for a long time and I am always surprised that programmers don't make more use of them.

The basic idea: When we (program designers) write a procedure it is with a purpose. "This procedure should blah-blah-blah with examples" Those examples, specified BEFORE we start writing the code form an acceptance test. "This procedure will be said to be successful if it satisfies these acceptance tests." In my example a very simple test that echoes BKnight's statement "113'27.5 would change to 113 + 27.5/32 or 113.859375, and this is the number from a string."
That is why I have a Debug.Assert as the sole test.

The macro runs with no complaint; no syntax or run-time error, just as it would if it were updating an Access Database. You run the macro, the computer goes click-whir, and the database is updated.
Of course with the database example you have no idea if the field in the record was updated; you would have to open the database and inspect the record. Not at all like a workbook or document where the result is visible on the screen.
So ("Computers are good at boring and repetitive tasks") you might write a bit more Access database code to have the computer inspect the record to confirm that, indeed, the record was updated.
That test would be expressed (roughly) as "If the record field now says 'Greaves' then the procedure must have worked!"

Now think what happens if six months down the road you need to make a change to the procedure. There is a chance that you make a change that affects how the procedure is supposed to work. Modifications then become a multi-step process:-
(1) Drag the TEST macro out and decomment it
(2) Run the TEST to confirm that the procedure still works as designed. (If it doesn't then we have a SERIOUS problem to solve, right?)
(3) Insert additional self-testing procedures. Perhaps this modification is supposed to take care of both single- and double-quotes. Or perhaps the procedure must accept a variable rather than a constant for that "32" value.
(4) Make the required programming changes to the target procedure.
(5) Run the TEST to confirm that the procedure works as designed WITH OUR MODIFICATIONS. If it does not, then we must find out why, fix the problem, and re-run the TEST. This is especially true for the original debug.asserts. If our modifications show that the original tests fail, then presumably all current procedures that depend on this procedure will fail, too. Our house-of-cards will topple.
(6) Once the TEST runs satisfactorily, comment the code and drag it back inside the procedure. (Truth is, the run of the Test is one keystroke <F5>, and recommenting the TEST is a simple Ctrl+Z to undo the decommenting)

Now you might take the procedure from Word2003 into Excel2025 or Access2030, and it travels with its own TEST, so the first thing you could do in Access (PowerPoint etc) is drag that TEST out, decomment and run it, and then stuff it back into the procedure.

I hope that this makes sense.
If you think about it, self-testing code ought to save hours of time during regular program maintenance.
In a big software house, procedure specifications are updated and the programmer signs off saying that the TESTs have been run and found correct. The upgraded TEST accompanies the documentation.

Some of my library functions have TESTS that are longer then the functioning code, but I maintain the library code with confidence.

Cheers, Chris

[ChrisGreaves]

And how about Ctrl+S? Isn't that the universal keyboard shortcut for Save in any language?

Hi Hans. Indeed yes, mot to mention my timed-save (OnTime) code in my Normal.dot.
Your response made me think. Why do I use Alt+F, S in the VBE but Ctrl+S everywhere else?
I am not sure, but I suspect it is to do with me wanting to remind myself that I am Saving not only my VBA code but also my project document or workbook.
Very strange!
Cheers, Chris

[ChrisGreaves]

Code: Select all

Function Convert2Num(Optional Price As String) As Double
    With CreateObject("MSScriptControl.ScriptControl")
(snip!)

Top Class! Watch out World! Here I come!

Question(1) Creating and dismissing an object has a cost of execution time, right?
Question(2) But the cost would be minimal? It's not like the cost of loading a copy of an MSOffice application (say MSExcel with all its DLLs and libraries), right?

I agree that your example is mobile, and suspect that I might code it that way if I were in a shop that was populated by MSScripters; give them something familiar to hang on to.
Cheers, Chris

[ChrisGreaves]

This is the code I have. Please submit any changes you fell are necessary.

Al has confirmed that the code I supplied works exactly as intended.
If you would like to go back and follow the steps you too should see that the code works exactly as intended. Then, if you like, we can go onto the next step of satisfying your original problem.
Let me know.
You are quite welcome to set off and do your own changes, of course.
Cheers, Chris

[SpeakEasy]

>Creating and dismissing an object has a cost of execution time, right?

1) Correct - so in a real solution I'd probably make sure I instantiated the object a module level or even globally (or at least with a scope that ensures it stays in existence for the entire time I need it); but

>The cost would be minimal?

2) Depends what you mean by minimal - cost is about 0.56ms on my PC to load and use the library call each time. Not a worry if you are only calling it a few times - but 10000 calls would represent over 5.5 seconds ... Using the call from a loaded in scope library is about 50 times faster

So the answer here would really be ... it depends ...

[bknight]

As I have indicated your code works if the Sub TESTstrSplitAt() is commented, which in the one I was worked was uncommented. Now lets get on to how to use the function. How do I enter a string like 114'21.5 and get it to your code to produce a number, that is the real issue.

[snb]

I'd use:

Code: Select all

Sub M_snb()
  MsgBox Val("113'27.5") + Split(Replace("113'27.5", ".", Application.DecimalSeparator), "'")(1) / 32
End Sub

[ChrisGreaves]

As I have indicated your code works if the Sub TESTstrSplitAt() is commented, which in the one I was worked was uncommented. Now lets get on to how to use the function. How do I enter a string like 114'21.5 and get it to your code to produce a number, that is the real issue.

My poor benighted soul: You began this topic with a request "I would like code to parse a string into numbers and it has an apostrophe in it."
I have provided tested code that parses "a string into numbers and it has an apostrophe in it. "
The solution has been tested by Al, and shown to work.

As far as I can see you have not satisfied yourself that my suggested code works, but have chosen to make your own modifications and then asked me to pursue your line of investigation.

The style of coding I employ has been implemented successfully for more than 25 years.

Now, indeed, " lets get on". I have asked you several questions in response to your comments and you have not answered them.

I will be happy to proceed once you have answered those questions.

I note in passing that you have 958 posts in Eileen's Lounge, over a period of 6+ years, the majority of those posts in Access and SQL, and a significant number in VBA. Are you telling me that you don't know how to pass an argument to a procedure? I'd like to know before I go any further.
Thanks, Chris

[ChrisGreaves]

I'd use:

Code: Select all

Sub M_snb()
  MsgBox Val("113'27.5") + Split(Replace("113'27.5", ".", Application.DecimalSeparator), "'")(1) / 32
End Sub

Hi snb. I think that this would be fine for an experimental approach, but I suspect too that what is required is a utility procedure that one can use for any syntactically correct string.
In VBA that means a function that takes a string argument and returns a numeric result.

The MsgBox is similar to using Debug.Print; it shows the result.
But Debug.Assert is what you need if you want to perform rigorous testing, now and into the future of the procedure. I suspect that this conversion is at the point of data-entry into the system, and it ought to be bullet-proof, yes?

Cheers, Chris

[snb]

@chris

Did you donwload the file and open it ?
BTW. Try thinking in suggesting approaches instead of offering solutions. The TS should be able to learn.