I am working to flush out some defects from an older program and I'm running into an issue with negative numbers in aebacus textboxes.
Basically, whenever a negative number (i.e. -1) is entered into a textbox, on focus lost the textbox shows the number with a trailing negative (i.e. 1-). On focus again, the number is displayed correctly as -1.
I have seen this in excel and maybe it is a formatting setting, or possibly just a limitation of vb6?
Apparently using a different font can fix it, in our case we made a custom font to alleviate the issue.
Related
Looking for some help or to be pointed in the right direction. Been stuck on this for a while and the main issue is I don't even know where to start. I am sure there is a solution but my brain will not see it.
To use as an example I have a table that shows monthly results for multiple different areas:
What I want to do is in the gap along side each number is show an increase, decrease or no change, using up arrow down arrow and square. That I can do using conditional formatting my issue comes with the fact that I also want it to be multiple Colours. So it will take into account increase and decrease and whether they are in target.See below:
Atm I am copying and pasting each month. But having it automated would be amazing. The outcome would hopefully look like this:
I am hoping there is a way that I can do two things compare to the previous month and then check it against my table to see where it sits then display the appropriate symbol.
Thank you in advance for any help or a place to start.
So extremely easy to figure out once I looked at it in a simplistic way.
Firstly, I used: =IF(-SIGN(E26-G26)= 0, "n", IF(-SIGN(E26-G26)=1, "é", IF(-SIGN(E26-G26)=-1, "ê","")))
To compare the current number to the previous number and get a 1, 0 or -1 depending on if it had gone up down or stayed the same, using this it either displays é, n or ê. I then set the font on these cells to Wingdings. so they become up arrow, down arrow and a square.
Then I use conditional formatting to colour it based on the adjacent cells value.
No need for a long, complex formula
=IF(A2>A1,"t",IF(A2<A1,"u","v")) - set the font to Marlett
I'm not sure whether this should be the expected behaviour or is a bug.
When the Row Number column is set to be shown, selection of (Auto Fit All Columns) from context menu stretches the column
to the end of the ListGrid.
I though there is an issue in our app but the ShowCase has (Grids > Appearance > Row Numbering)
the same problem.
final ListGrid countryGrid = new ListGrid();
countryGrid.setWidth(500);
countryGrid.setHeight(224);
countryGrid.setShowAllRecords(true);
countryGrid.setShowRowNumbers(true);
If you change the width of a column before applying the Auto fit it behaves normally.
Has someone had the same issue ever?
Is there any workaround?
Without looking further at your code (for instance, other width and autofit related configurations applied to the list grid, field types and expected contents) it's difficult to know if this is expected behavior. Although I agree, by looking at the demo, that it is at least strange behavior.
But this is what I do in my ListGrids to keep the row numbers at the size I want:
// this field is created only as a way to define the row number field properties
ListGridField rowNumberFieldProps = new ListGridField();
rowNumberFieldProps.setWidth(50);
rowNumberFieldProps.setCanAutoFitWidth(true);
rowNumberFieldProps.setAutoFitWidthApproach(AutoFitWidthApproach.VALUE);
grid.setRowNumberFieldProperties(rowNumberFieldProps);
grid.setShowRowNumbers(true);
Some notes:
Since I expect a lot of records to be displayed (and in consequence, large row numbers), I use a row number column width that fits properly my numbers (50 in my case).
Notice that setCanAutoFitWidth(false) will leave your row number field fixed in size, even when 'Auto Fit All Columns' is used. This is probably a good approach in your case. If you do that, you can simply remove the line with setAutoFitWidthApproach.
setCanAutoFitWidth(true) and setAutoFitWidthApproach help me control what happens when I use the 'Auto Fit All Columns' context menu. In my case I do want autofitting to apply to extend the column width when I have row numbers beyond 99.999 (not the most common case for me, but possible).
I'm using PHP to generate docx documents from a database. The generated document contains column charts which have labels attached (i.e. user shapes containing textboxes). In an attempt to get the textboxes to accommodate and display all of the text (i.e. it shouldn't be necessary for the user to resize a textbox to see all the text) my code calculates how many characters will fit into 3cm, adds linefeeds to the string as required and tells me how many lines of text are needed. I have:
<a:xfrm xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main">
<a:off x="1638276" y="1676399"/>
<a:ext cx="1257325" cy="'.(252000 * $labelLeftLines).'"/>
</a:xfrm>
which I believe should give me a text box around 3.5cm wide (extra .5 for the internal padding) and a height of .7cm multiplied by whatever is the value of $labelLeftLines. However, the text box always turns up as 3.cm wide by .86cm high, which only ever displays one line of text.
If I add in 'autofit':
<a:bodyPr xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" vertOverflow="clip" wrap="square" rtlCol="0">
<a:spAutoFit/>
</a:bodyPr>
the generated file looks just the same, though, when I right click on the textbox to inspect the properties, 'autofit' is indeed applied. I have to uncheck it and recheck it to make it affect the textbox.
Any openXML gurus out there?
Hmm, some random floundering around revealed that the values I need to manipulate are here:
<cdr:relSizeAnchor xmlns:cdr="http://schemas.openxmlformats.org/drawingml/2006/chartDrawing">
<cdr:from>
<cdr:x>0.47</cdr:x>
<cdr:y>0.75</cdr:y>
</cdr:from>
<cdr:to>
<cdr:x>0.67</cdr:x>
<cdr:y>1</cdr:y>
</cdr:to>
Changing those values does actually change the size of the texbox, though I haven't a clue what units are being used. From 0.75 to 1 produces a height of 1.43cm.
One day I'll maybe be able to find my way around the doucmentation.
I am writing a vba macro that checks that word documents are formatted correctly to meet certain specifications. One of the things I have to check for are the left margins of each line - different paragraphs are supposed to have different first indents and hanging indents depending on the context. This should be as simple as checking the style, but unfortunately it is not - some of the documents use styles to change the indents, but others use manual spaces and tabs to position the text correctly. So I need some way to check the actual physical position of the first physical character in each Document.Paragraphs. I have no problem getting a range with the first visible character in the paragraph, but I'm not sure about getting the distance from the margin (or from the left side of the page - doesn't make a difference because the margins are consistent).
I found the Window.GetPoint method, but I'm nervous to use it, because that is based on the actual physical location on the screen. This macro is going to be used on different computers, with different versions of word, and I'm not sure about how it is affected by other view settings (like print layout, zoom, etc.) Is there a consistent way to use this method to determine the distance from the margin?
The other method would be (because all of the documents are in Courier New 12) to look at the firstindent property of the style, and the count manually all of the spaces and tabs (but that would need to take into account tabstops). This I'm also not sure how to do.
I would think that there should be a much simpler way of doing this, but I can't find it, so if anyone has any suggestions I would really appreciate any help.
It was there after all! Range.Information(wdHorizontalPositionRelativeToPage)
I am having some issues with the TRichEdit.
The first issue is if I try to paste a lot of text from the clipboard into a empty TRichEdit, it truncates the bottom of the text.
The second issue, which I guess ties into the first issue, is that I seem to be limited to how many characters the TRichEdit can display, hence pasting from the clipboard is losing some of the data.
If I paste into a TJvRichEdit (Jedi), that works fine, obviously because that is a completely different component.
At this moment in time I would like a solution for the TRichEdit because I am using a lot of procedures/functions etc, if I change to a different Rich Edit class then I will have to edit a lot of my code to work.
So basically what I am asking is:
Is there a limit in the TRichEdit? which I am sure there is.
How can I increase the limit of the TRichEdit to accept more characters and lines etc.
Please provide advice/solution for TRichEdit only.
EDIT
never mind found the answer using:
RichEdit11.MaxLength := $7FFFFFF0;
Quoting an answer given by David Pate from the newsgroups:
The following remarks apply to the versions of Delphi that use the Windows Richedit version 1 control. I understand that this includes all Delphi versions prior to version 7. (I do not know what the situation is when you run programs compiled in these versions on the various NT/2000 versions of Windows although Windows XP behaves as described.)
Q. What is the limit to the amount of text that a Richedit can hold? A. The help files (Delphi help and Win32 SDK) are confusing, contradictory and incorrect on this point. There are 5 limits to be considered
The Maximum Capacity: the "hard-wired" limit, i.e the maximum size of the RichEdit's text buffer. It is 2 bytes less than 2 Gb. Note that this is the theoretical limit; in practice the limit will be determined by your computer's memory.
The Capacity: the actual size of the current buffer. By default, it is 64Kb but can be resized by several means.
The "Keyboard limit": the limit beyond which characters cannot be added by typing from the keyboard. It is often different from the Capacity but, like the Capacity, it is by default, 64Kb and can be resized by several means.
The MaxLength property of the tRichEdit object. The default of 0 sets both the Capacity and "Keyboard limit" to 64Kb.
The line-number limit: theoretically this is around 134 million, but in practice, you can expect to get much less than this. The maximum number of lines seems to depend on several factors including the amount of memory available and the average length of the lines. I find that I can get around 150 thousand to 200 thousand lines. Note also that it has been reported that some releases of the Windows 95 Richedit control sometimes throw an exception when more than a few hundred lines are added. This appears to be due to a bug in the control and to have been corrected in later releases..
Q. How can I increase the amount of text that a tRichEdit can hold?
A. When you add text programmatically, both the Capacity and the "Keyboard limit" are resized to accommodate the text being added. By adding text programmatically, I mean using any of the Add, Append, AddStrings or Assign methods of the tRichEdit.Lines property or the LoadFromFile, LoadFromStream or SetTextBuf methods of tRichEdit. Note that adding text in this way does not update the MaxLength property.
B. By using the MaxLength property. This sets the "Keyboard limit" to the value passed to MaxLength. It also increases the Capacity to match the "Keyboard limit" if the existing Capacity is less than MaxLength. Note that you cannot use MaxLength to reduce the Capacity and that changing MaxLength has no effect if the value passed is less than the length of the text currently in the control. To increase the Capacity and the "Keyboard limit" to the same value, set the tRichEdit.MaxLength to the desired value. To set the maximum size in the Object Inspector, use the value 2147483645 ($7FFFFFFD). To set it programmatically it is simpler to use .MaxLength := System.MaxInt-2;. The EM_LIMITTEXT and EM_EXLIMITTEXT messages may also be used to change the "Keyboard limit" and Capacity but I'd not normally recommend using them since, if you do, you will not be updating the MaxLength property.