Is there a way to make sure that numbers are entered into an EditBox in a specific format?
ie when someone types 11 it adds a . after it so if someone types 1124 it will recorrect when it gets to the end of the second 1 and adds a . making it 11.24. This is intended for currency. This is made for an TEdit
Thanks
The easiest way is to use a TMaskEdit for this; it's what it was designed to do.
MaskEdit1.EditMask := '00.00'; // requires two digits before and after
// the decimal point
See the documentation for TEditMask for more information about the types of mask characters you can use.
Yes, the "mask" property. Check help.
Related
I would like to understand the differences between the next parameters:
smpp.data_coding
smpp.dcs
smpp.dcs.charset
It seems to be that the vale of smpp.data_coding and smpp.dcs always match. However, I'm not sure if the value of smpp.dcs could be different of the value of smpp.data_coding.
I was looking for some information, but it isn't still clear for me, so I appreciate your help.
Thank you.
Kind regards,
I am not sure if its gonna help, maybe you have read it already but there is not much of the difference contextually between data_coding and dcs. However, data_coding field is restricted to sharing 1 byte of value and representing what coding is being used. While, with dcs in addition to the 1 byte of data that is associated about the coding scheme, we also get additional attribute fields like - charset.
This may not be significant in general sense, but check this out - https://helpx.adobe.com/in/campaign/kb/smpp-protocol-wireshark.html
The data_coding field tells you which encoding is used. The only problem is that the value 0 means default SMS-C encoding in the specification, but in general it means GSM7. Check with the SMS-C partner what encoding is associated to data_coding = 0 (Adobe Campaign only supports GSM7 for data_coding = 0).
Hence, while value of data_coding and dcs might look same, dcs.charset helps identify the character set being used and hence the message size too.
Maybe you have figured it out already..
I have a timetabling program I'm working on for my project and I'm working on adding error messages, I have a form with 5 edit boxes, entering values in this field update the times shown next to the periods on the timetable program (think like 06:45-08:45 and next one down says 09:00-11:00). I've stopped from someone entering a too long a string like 'OMGISTHISATEXTBOX'.
I'm trying to work out a way from showing an error message when the user enters anything with a char (letter), or not allow anything but integers and a hyphen symbol and a colon (-,:). I assume not allowing char values is easier, but doing the latter if possible would be amazing.
Many thanks for your help and hope this makes sense, if you need more info lemme know
-Adam
There are special components for these purposes:
TMaskEdit is intended for input restricting.
For time input you can use also TDateTimePicker
As the title says, I would like to know what is the meaning of the pipe (or tube) "|" in a Delphi code. See that screenshot :
I know the meaning of "*" which is a wild card for one or more characters, but I can't find what means "|".
Thanks
This is a question that can be answered by reading the documentation. It can be found here:
Vcl.Dialogs.TOpenDialog.Filter
To create file masks in program code, assign a value to the Filter
property that consists of a description and a mask separated by a
vertical bar (pipe) character. Do not include spaces around the
vertical bar. For example,
OpenDialog1.Filter := 'Text files (*.txt)|*.TXT';
Multiple filters should be separated by vertical bars. For example,
OpenDialog1.Filter := 'Text files (*.txt)|*.TXT|Pascal files (*.pas)|*.PAS';
To include multiple masks in a single filter, separate the masks with
semicolons. This works both in the Object Inspector and in program
code. For example,
OpenDialog1.Filter := 'Pascal files|*.PAS;*.DPK;*.DPR';
You might like to absorb the hints found here (How can I search for Delphi documentation?) in order to help you in the future.
In Delphi, the | character is often used as separator in certain string properties to differentiate between:
The description and the mask of a file filter, as used in TOpenDialog.Filter.
The short part, the long part and the image index of a hint text, as used in all Hint properties.
The pipe separates the filter expression (on the right) from the caption the user will see (on the left). If you want to apply more than one filter, just append it, also separated by pipes.
For TOpenDialog this is just a syntax to specify in one line of Filter both:
friendly type name (here: Regles de chaurfage)
file extension related to the type (here .fuz)
This is not language operator. This is just some kind of convention TOpenDialog is using.
Multiple filters should be separated by vertical bars.
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Dialogs_TOpenDialog_Filter.html
I'm working in Delphi 7 and trying to make an edit box where you can enter decimals.
There doesn't appear to be anything in the Delphi 7 base library for this other than TCurrencyEdit. However, it tacks on a $ to the beginning of the value. Is there anyway to get rid of this "feature"?
(Can't you enter decimals in an ordinary TEdit?)
As far as I know, there is no TCurrencyEdit in the VCL that ships with (any version of) Delphi. Anyhow, for this, you could use the TMaskEdit. Perhaps the format #999999999.99;1;_ will do. Still, I wouldn't praise this solution for its user-friendlyness!
The most user-friendly thing to do, I believe, is to use an ordinary TEdit with no restrictions. Then you can parse the text entered by the user when you need to. And then you can accept inputs like 1 000 as well as 1000 and 1000.00. You can even respect the local decimal separator, and accept 1000,00 (in Sweden, for instance).
[But make sure that there is no ambiguity. The user might get upset if he enters 1000,000 and considers this to equal 1000 kronor and 000 öre, and then you take 1000000 kronor from his account!]
I was getting advice from Rob Kennedy and one of his suggestions that greatly increased the speed of an app I was working on was to use SetString and then load it into the VCL component that displayed it.
I'm using Delphi 2009 so now that PChar is Unicode,
SetString(OutputString, PChar(Output), OutputLength.Value);
edtString.Text := edtString.Text + OutputString;
Works and I changed it to PChar myself but since the data being moved isn't always Unicode in fact its usually ShortString Data.... so onto what he actually gave me to use:
SetString(OutputString, PAnsiChar(Output), OutputLength.Value);
edtString.Text := edtString.Text + OutputString;
Nothing shows up but I check in the debugger and the text that normally appeared the way I did it building 1 char at a time in the past was in the variable.
Oddly enough this is not the first time I ran into this tonight. Because I was trying to come up with another way, I took part of his advice and instead of building into a VCL's TCaption I built it into a string variable and then copied it, but when I send it over nothing's displayed. Once again in the debugger the variable that the data is built in... has the data.
for I := 0 to OutputLength.Value - 1 do
begin
OutputString := OutputString + Char(OutputData^[I]);
end;
edtString.Text := OutputString;
The above does not work but the old slow way of doing it worked just fine....
for I := 0 to OutputLength.Value - 1 do
begin
edtString.Text := edtString.Text + Char(OutputData^[I]);
end;
I tried making the variable a ShortString, String and TCaption and nothing is displayed. What I also find interesting is while I build my hex data from the same array into a richedit it's very fast while doing it inside an edit for the text data is very very slow. Which is why I haven't bothered trying to change the code for the richedit as it works superfast as it is.
Edit to add - I think I sorta found the problem but I have no solution. If I edit the value in the debugger to remove anything that can't be displayed (which by the old method used to just not display... not fail) then what I have left is displayed. So if it's just a matter of getting rid of bytes that were turned to characters that are garbage how can I fix that?
I basically have incoming raw data from a SCSI device that's being displayed hex-editor style. My original slow style of adding one char at a time successfully displayed strings and Unicode strings that did not have Unicode-specific characters in them. The faster methods even if working won't display ShortStrings one way and the other way wont display UnicodeStrings that aren't using non 0-255 characters. I really like and could use the speed boost but if it means sacrificing the ability to read the string... then what's the point in the app?
EDIT3 - Alright now that I've figured out that 0-31 is control char and 32 and up is valid I think I'm gonna make an attempt to filter char and replace those not valid with a . which is something I was planning on doing later to emulate hex editor style.
If there are any other suggestions I'd be glad to hear about them but otherwise I think I can craft a solution that's faster than the original and does what I need it to at the same time.
Some comments:
Your question is very unclear. What exactly do you want to do?
Your question reads terrible, please check your text with a spelling checker.
The question you are referring to is this one: Delphi accessing data from dynamic array that is populated from an untyped pointer
Please give a complete code sample of your function like you did in your previous question, I want to know if you implemented Rob Kennedy's suggestion or the code you gave yourself in a following answer (let's hope not :) )
As far a I understand your question: You're sending a query to your SCSI device and you get an array of bytes back which you store in the variable OutputData. After that you want to show your data to the user. So your real question is: How to show an array of bytes to the user?
Login as the same user and don't create an account for every new question. That way we can track your question history an can find out what you mean by 'getting advice'.
Some assumptions and suggestions if I'm right about the true meaning of your question:
Showing your data as a hex string won't give any problems
Showing your data in a normal Memo field gives you problems, although a Delphi string can contain any character, including 0 bytes, displaying them will give you problems. A TMemo for example will show your data till the first 0 byte. What you have to do (and you gave the answer yourself), is replacing non viewable characters with a dummy. After that you can show your data in a TMemo. Actually all hex viewers do the same, characters that cannot be printed will be shown as a dot.
I used PAnsiChar in my example for a reason. It looked like OutputLength was being measured in bytes, not characters, so I made sure to use a type whose length is always measured in bytes. You'll also notice that I showed the declaration of OutputString as an AnsiString.
Since the edit control stored Unicode, though, there will be a conversion between AnsiString and UnicodeString. That will take the system's current code page into account, but that's probably not what you want. You might want to declare the variable as a RawByteString instead. That won't have any code page associated with it, so there won't be any unexpected conversions.
Don't use strings for storing binary data. If you're building what amounts to a hex editor, then you're working with binary data. It's important to remember that. Even if your binary data happens to consist mostly of bytes that can be interpreted as text, you can't treat the data as text or you'll run into exactly the problems you're seeing — characters that don't appear as expected. If you get a bunch of bytes from your SCSI device, then store them in an array of bytes, not characters.
In hex editors, you'll notice that they always show the hexadecimal values of the bytes. They might show those bytes interpreted as characters, but that's secondary, and they generally only show the bytes that can represent ASCII characters; they don't try to get too fancy with the basic display. The good hex editors will offer to display the data interpreted as wide characters, too. This aids in debugging because the user can look at the same data in multiple ways. But they're just views of the data. They're not actually changing the binary contents of the data.
When you filter out non viewable characters...You'll probably need to decide what to do with a couple of them like #9(Tab), #10(LF), #11(Verticle Tab), #12(FF-or New Page),#13(CR)