Latest Visio Version not handling VBA changing character size

[wapperdude]

Worth a try.  I don't believe it to be an issue since the simpler code without the loop also experienced same difficulties.  As it works fine on your setup, I'm suspecting a local corruption of some sort.  It would be nice to find something definitive to provide to the OP.

[paulv45]

Thanks for helping here Yacine & wapperdude.

I'm looking at finding an immediate term solution while ultimately seeking a long term solution.

I think we have clearly identified a bug in the latest Visio release.
The long term solution is to see if we can (A) get MS to fix or (B) develop a workaround.

In the immediate term I took a look at downgrading to an earlier version and found:
https://support.microsoft.com/en-us/topic/how-to-revert-to-an-earlier-version-of-office-2bd5c457-a917-d57e-35a1-f709e3dda841
Following the relatively simple steps there I successfully loaded: Visio Version 2108 (Build 14326.20238)
This fixed the problem in my ultimate application.  I was not surprised, but pleased.  We are on the right track.
If you try this note the xxxxx.yyyyy in the config file is the build ID -- 14326.20238
So the line is:
<Updates Enabled="TRUE" TargetVersion="16.0.14326.20238" />
The build ID is specific to Visio and you will not find it in the reference doc.
Also in the reference doc is says turn off updates in Outlook, but I did this in Visio.

So this was successful on my System B.
I have a more complicated environment on my System A and that's my next step and will report here when get that working.

Then on to the long term solution.

Looks like you are working the workaround approach.  Thanks for that.

Any idea if we could get MS to look at problem introduced in latest release?

[vojo]

good luck with A) !!!   

MS spends more time introducing bugs and depreciating functions than fixing bugs and adding new (useful) functions

[wapperdude]

@Yacine:
  >. Tried the DoEvents to no avail.
  >  Did Visio uninstall /re-install.  That didn't help either
  >. Tried a delay timer at a couple different code locations.  No help.

So far, no techniques have yielded a correct code execution. 

[paulv45]

wapperdude -- wondering if you looked at the version details and tried the install earlier version noted in my last post.

[Yacine]

@Paulv,
Pardon the heretical question, but would it be thinkable to switch to a "right" implementation?
What I mean is that text formats are a quite fragile way of storing data (as you are just experiencing).
A better place for data are prop fields. You can insert them as fields and still do your formatting as needed.
A macro could transform all the existing shapes in one go and you would end up with a much stronger structure.
... just my 2 cents. I will understand if you first reject categorically this idea, but you may spend some minutes on it.

[paulv45]

@Yacine:
Certainly want to go to the higher ground solution, but I have working code in several places that I need to fix, test, etc.
It's a time to solution issue -- immediate term and long term.
Am working immediate term on my System A at the moment.  Then onward.

[Yacine]

I noticed in Wapperdude's screenshots that the first instance was in both cases properly formatted.
If this is everytime true, them maybe there is something with the characters object being corrupted when modified.
I can't try it by myself, since I don't get the errors, but would you guys try to re-instantiate this object after each modification?
To explain:
not:
  set o_chars = shp.characters
  for i = ...
    pos = find
    o.chars = begin...

but:
  while find = ...
    o.chars = shp.characters
    o.chars ...

in other words move the set allocation inside the loop.

[wapperdude]

@Yacine: 
So, after being more methodical, I noticed that the Chars section must start with a single row setup.  The macro only acts on 1st row.  That was creating some of the inconsistent results. 

Once, a correct starting condition is defined, then the <f8> approach always works correctly.  Stepping thru the code, you can watch as each "the" is made bold, then resized, and then moves to next "the".  Normal code execution also provides consistent, identical response.  Namely, ALL text is bold and shrunk to the new size.

Looking at shapesheet, the <f8> single line execution produces multiple rows in Char Section.  This would be the expected, correct behavior.  With the normal execution mode, only a single line is present with new values for Style and Size.  The single affects the entire text string.

Your comment about messing up the Char string, might be a possibility, if, somehow the indexing gets clobbered...like when iteratively deleting a bunch of shapes.  Will try starting at end of string and work backwards to the beginning.

[wapperdude]

Other than being a little weird, there were no result changes by stepping backwards.

About reinstalling. .. I did uninstall, then cleaned registry.  The installation file says "office", and does access the web as it prepares the installation.  I'm wondering if that includes all available updates.  I get no notice of needing office updates.  Plus, the addins, e.g., Paul's Super Utilities, and others are also reinstalled.  So, it doesn't seem like I'm back to original config.

[paulv45]

I am continuing to struggle getting my System A to load the earlier version.
I'm guessing I am experiencing the same thing as wapperdude.
It acts like downloading the earlier version but doesn't seem to.
Going to try on system with no Visio installed, just downloading the earlier version.

[paulv45]

Here's my latest experience...
The latest release of Visio:
Version 2204 (Build 15128.20178)
Fixes the problem in the simple demo but my code still fails.
Would be interested in your experience, wapperdude.
Before trying to develop another simple test to show issue, planning to look more closely at Yacine's suggestion.

[paulv45]

Continuing to beat on this with no success.
Like wapperdude, if I put a break before
objChar.CharProps(visCharacterSize) = 8#
and then execute with <f8> life is good.   The 4 characters are set to 8 per Begin and End.
If I just let it run with no break, all of the text is set to 8.
I've tried screen update off/on and timer function -- no success.
MsgBox before the CharProps line requiring user response works too but is pretty brutal.
So far only Break and MsgBox avoid the problem introduced some time after 2108.
I am baffled by this behavior.

A fun fact -- in a 2108 experiment I accidentally set begin and end after last character in text and this exhibited bad behavior -- all char in text to 8.

[paulv45]

@Yacine
It seems your code also runs fine for me.
Also, I don't understand how prop fields would play.

[Yacine]

Also, I don't understand how prop fields would play.

The whole text would be split into its main components.
prop.main_text = "so and so"
prop.extra_data = "xyz 123"
and you would insert those field into the shape's text.
You would also protect the text, so users don't overwrite the fields.
The second field you be formatted bold and whatever.


You can get fancy with those fields if you object, that users absolutely need to enter the main text in the shape directly.
Then you would unprotect the text, but hide it. The text would then be written to a sub-shape (not hidden).

Second possible objection: you have tons of drawings based on the old method.
prepare a master with the 2 a.m. props.
iterate over all the shapes and replace them by the new master - now the props are available - and write the text of the shape into the main prop. The second one could be parsed by means of checking the rows of the char section.

This all may sound complicated - I agree. At the end it will still be more robust.