Solved How to grow and shrink name horizontally (1 Viewer)

SuperSonicSam

New member
Local time
Today, 23:12
Joined
Jul 16, 2023
Messages
23
Looking for a way to grow and shrink horizontally the name (together with the associated boarder and identifiers) to accommodate longer and shorter name lengths. The movement would need to occur only on the left hand side and the right hand side needs to remain fixed in place. BTW name on report is fictitious.
 

Attachments

  • 20230717_071032.jpg
    20230717_071032.jpg
    50.6 KB · Views: 78

theDBguy

I’m here to help
Staff member
Local time
Today, 06:12
Joined
Oct 29, 2018
Messages
21,473
Sorry, I'm not following. Can you provide some more examples to help clarify what you mean?
 

SuperSonicSam

New member
Local time
Today, 23:12
Joined
Jul 16, 2023
Messages
23
No problem .....so if the name on the report was say Frederick Samdombestonsen (I.e. a much longer name), then this wouldn't fit within the existing formating. In order to accommodate this longer name the txt box would need to expand significantly in the left direction. Just let me know if still not clear (I am a beginner)
 

theDBguy

I’m here to help
Staff member
Local time
Today, 06:12
Joined
Oct 29, 2018
Messages
21,473
No problem .....so if the name on the report was say Frederick Samdombestonsen (I.e. a much longer name), then this wouldn't fit within the existing formating. In order to accommodate this longer name the txt box would need to expand significantly in the left direction. Just let me know if still not clear (I am a beginner)
So, are you saying the size of the box should stay the same and only the font size for the name should change to fit within the box?
 

SuperSonicSam

New member
Local time
Today, 23:12
Joined
Jul 16, 2023
Messages
23
No, I'd like the size of the box to increase (to the left) and the font size to stay the same
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 08:12
Joined
Feb 28, 2001
Messages
27,186
You can manually resize the box (assuming you have room for it) by just computing the desired width in twips (1440/inch) and then reloading the box's .Width property (which is in twips). However, you can easily compute the size only with non-proportional fonts e.g. Times New Roman as the most common example, or Lucida Console as popular alternative. With non-proportional fonts, the string length in characters times the width of a character in that font gives you the answer, though I don't recall that two different non-proportional fonts are uniform in width for the same font size. Even the difference between normal and bold or normal and italic can complicate the works.

Many people use proportional fonts like Arial or Bookman Old Style as a matter of aesthetics, and there the sizing issue becomes much trickier. Individual character widths are not uniform so you cannot just multiply characters times font width. Routines exist in Excel that can determine the visible length of a string in a particular proportional font (face & size). Native Access doesn't have such a function. You would need to bring in the Excel library among your references to use the appropriate function in Access.


The problem is when you deal with proportional fonts, the pixel width isn't easy to determine, particularly if kerning is in force, since in that case you need to know if it has occurred, and if so, how many times. Kerning, if you weren't sure, is the ability to slightly overlap letters when their serifs don't touch, so they take up less space than you might have expected.

Now if you don't care about a little non-uniformity of your text box when using proportional fonts, you COULD just center the text in the box and then compute it as number of characters times the width of the widest character in that font (which you might have to look up or measure.) In cases with lots of L and I (like Williams, e.g.), the name might have a little extra blank space at the ends vs. other names with the same number of characters, and I won't swear that the centering will be perfect either if the kerning was concentrated at one end or the other.
 

SuperSonicSam

New member
Local time
Today, 23:12
Joined
Jul 16, 2023
Messages
23
Many thanks The_Doc_Man & Isladogs! Definitely not as straightforward as I was hoping but lots of information for me to look into. Thanks again.
 

Cotswold

Active member
Local time
Today, 14:12
Joined
Dec 31, 2020
Messages
528
Why not adjust the size in OnLoad()?
Only problem is that you'll need to do the calcs in Twips, not pixels. As an example on one of my screens at 1920x1080 on the Access report a field 14cm long is about 8000 Twips.

So you could do a Len() on the name and decide the size in Twips for your screen. Len(Me!Field) multiplied by a number to give you the size you need, then Me!FieldNameOnReport.Width = 8000 or whatever. Maybe if you used a set font like Consolas it would be easier than with TTF?
Possible you'll need to swot up on Twips and how may to a cm or inch on your screen?

I shift buttons and other Objects about on a form in OnLoad() all the time, and it seems to work on a Report. ( I just did a little test and changed a Field's position and Width on a report )
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 08:12
Joined
Feb 28, 2001
Messages
27,186
Why not adjust the size in OnLoad()?

That is one place where you can diddle with controls. OnLoad means the controls have been loaded even though they might not yet have data in the bound ones. I used to do my rearrangement in OnCurrent because I had some control buttons that were dynamically altered to represent the things you could do to that record based on its current status, which changed with each navigation. Controls aren't available until AFTER OnOpen because there, you have just opened up the form. Think of it like unpacking a suitcase. You can't hang up the clothes until you open the suitcase. You can't see the clothes to put them on until you have hung them up. If it weren't that the Load and Unload are reversed for the suitcase analogy, it would be perfect.
 

Cotswold

Active member
Local time
Today, 14:12
Joined
Dec 31, 2020
Messages
528
Adjusting Objet positions in OnCurrent() I haven't attempted.
I once mentioned on the Forum that when a form opens I have a function called from OnLoad() that can set eight standard buttons to four different positions on a form, where they remain. The function will shift them from being alligned horizontally along the bottom of a form, or to be on the right and vertically alligned. Ditto to the top or left. I was critisised and told in no uncertain terms that moving objects using code to change their design locations was something that shouldn't be done under any circumstances.

Obviously I gave the remarks the amount of attention and consideration they deserved.........zero!
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 08:12
Joined
Feb 28, 2001
Messages
27,186
I was critisised and told in no uncertain terms that moving objects using code to change their design locations was something that shouldn't be done under any circumstances.

Obviously I gave the remarks the amount of attention and consideration they deserved.........zero!

I concur whole-heartedly. In my case it was command buttons that depended on information in the bound record to determine whether the business rules allowed certain actions. I only showed the commands that were allowed AND I moved the buttons to avoid having gaps in the set of remaining commands. For instance you did not have any visible controls to close a dirty form. You could never see CLOSE and SAVE at the same time. Nor could you see CANCEL and CLOSE together. Things like that reduced the things that people could do wrong.
 

Users who are viewing this thread

Top Bottom