проблем с "г." в датата с Delphi

как мога да се освободя от проблема с "г." на датата без да махам от настройките на Windows "г." от изписването на датата му?

чакам с нетърпение

Не разбрах в какво точно ти е проблема и какво ти пречи "г.", което хем да не го пипаш, хем да не ти пречи.

проблема е в това: да не махам "г." от настройките на датата на виндовса а на делфи когато слагам дата в DBEdit поле за дата да не ми казва че датата е с невалиден формат ако иам "г." накрая на датата(годината)

Една примерна програмка на Pascal. Лесно можеш да си я преведеш и на друг език
{премахва букви от дата }
function CorrectStrDate(Value : String): string;
var II : byte;
begin
for II:=1 to length(Value) do // дължина на датата в брий символи
if not (Value[II] in ['0'..'9',DateSeparator]) // DateSeparator е разделител в датата установен в конкретния Windows
then Value:=copy(Value,1,II-1); //остават само символите за датата
REsult:=Value;
end;

Моето ли4но решение след доста борба по конфигурирането на Делпи + BDE + Windows Regional Settings е да я махнеш - не 4е не може да се нагласи и така да работи BDE - то ама е глупаво защото ако не конфигурираш Reg. Sett. ще конфигурираш BDE всеки път когато инсталираш програма.
Освен това можеш да настроиш програмата си след стартиране да има по - специфи4ни формати - примерно да пише имената на месеците на български, да има за decimal separator "." и вси4ки други неща които има в Regional Settings така 4е да не ги променяш. Ама при вси4ките тези възможности - е необходимо винаги (не знам защо) конфигурацията на датата и 4ислата в BDE и Win-a да съвпадат. Така 4е махай 'г.' - то и дишай по леко когато се отняся до бази данни - най-ве4е свързаните с BDE

това с програмката на паскал е ясно - от там минах и аз, но жсе пак благодаря а що се отнася до това да махам "г. " от виндовса е най-лесно, но някой хич не са доволни да им се променят такива "основни" неща.
значи продължавам да си бласкам в тая насока, но все пак благодаря

целувки

Не пипай "г.". Само когато имаш обработки с полетата за дата, използвай това конвертиране. В моите програми "г." се вижда, но там, където използвам датата за смятане. я минавам през тази програмка

И аз нещо не разбрах:
Нали при конвертирането от низ към дата (например в DB-контрол) Delphi-то си използва за преобразуване формата, зададен в променливите на SysUtils и които ги инициализира с Windows-ките настройки. Т.е. като си промениш променливите ShortTimeFormat или LongTimeFormat (не съм сигурен кое се използва в DB-контролите) получаваш точно това, което искаш...

Правилно - оба4е DB контролите май освен тези настройки използват и настройките на БДЕ - оба4е не съм сигурен кое къде и как ама има някква каша. Освен това много внимвай със SysUtils - имах кошмарна седмица преди около месец - историята е много странна, но поу4ителна затова ще я разкажа
Та имам си ДБ програмка с една таблица (имам дата и номер в нея - е не само) и две контроли - с дата. В тези контроли си задавам старт и стоп датата на записите които ще се показват от таблицата. Та взимам си датите от двете контроли и ги конвертирам от TDateTime в стринг със следния вид dd/mm/yyyy
за да ги подам на SQL заявката за да филтрирам таблицата (има и по елегантен на4ин без да се използва конвертиране на датата в стринг ама - глупост - едно време само толкова знаех).
За конвертирането използвам точно функциите от SysUtils. Вси4ко е 6 докато (забележи липсата на явна връзка) не покажа и скрия таск бара - на Win -а. Изведнъж заваляват купища от грешки - от SQL заявката 4е нещо не е както трябва - или по то4но константата (? не съм сигурен ) се беше променила (?!?) и конверсията ставаше не по dd/mm/yyyy а по mm/dd/yyyy - трудно е за вярване но беше факт. Сещаш се за какво гърмеше SQL - а ами дата от вида
16/01/2001 - беше много интересна във формат mm/dd/yyyy. Ина4е на екрана вси4ко беше Ок. Та най вероятно 4асовника сменя формата и незнайно как вси4ко това се отразява на SysUtils - овите константи.
Така и не успях да повторя този номер на комп. на който разработвах програмата - разни Виндовси - и други простории.
Та странни неща и внимавайте с предефинирането на константите в SysUtils. Аз също го ползвам ама има понякога и такива идиотски слу4ки.

Ей-това:
DateSeparator := '.';
ShortDateFormat := 'dd.mm.yyyy';
DecimalSeparator := '.';
LongMonthNames[1] := 'ЯНУАРИ';
LongMonthNames[2] := 'ФЕВРУАРИ';
...
LongMonthNames[12] := 'ДЕКЕМВРИ';
помага в повечето случаи. Поставя се в главната форма на
програмата, при обработка на събитието OnCreate.

Генерално решение на проблема е да използваш DateTimePicker там където има работа с дати. Естесрвено има си и проблем: DateTimePicker не е закачен за recordset-а, тоест, ти трябва да го пълниш/четеш.
Когато става въпрос за DBGrid горната идея просто умира.
Тогава трябва да режеш гадните символи. Сега гледам как да прихванеш писането в дадено поле за да можеш да обработиш това което постваш.

Колкото до въпроса ако системната/усерската настройки са със г. дали database-то ще се оправи с това което вкарваш: НЕ, НЯМА ЕЗИК/ЕНГИН КОЙТО ДА СЕ ОПРАВИ С БУКВА В ДАТАТА. Това е положението, повярвайте ми, борил съм се с този проблем до припадък.

А Картаген... вие си знаете за Картаген
s/Картаген/Модератор/g

това решение работи за г. в края на стринга, но води до интересни резултати ако грешния символ е в средата на стринга...
така като гледам си се пробвал да махаш всички грешни символи от датата.
Ако питаш мен това е по-правилно решение (естествено, по-бавно е и гълта повече памет):

function CorrectStrDate(Value : String): string;

var II : byte;

    sResult : String;

begin

sResult := '';

for II:=1 to length(Value) do begin

    if (Value[II] in ['0'..'9',DateSeparator]) then begin

       sResult := sResult + Value[II];

    end;

end;

//проверка за случай че във формата за дата е включен 'паразитен' стринг, който съдържа сепаратора

if sResult[length(sResult)] = DateSeparator then sResult := Copy(sResult,1,length(sResult) - 1);

REsult:=sResult;

end;

апропо, това също не е напълно завършено - ще има проблем ако 'паразитния' стринг съдържа, примерно, два пъти сепаратора. Обаче ме мързи да го оправям - ако някой не си е написал собствено решение и реши да използва това - да го има впредвид.

А Картаген... вие си знаете за Картаген
s/Картаген/Модератор/g

И аз съм се сблъсквал с подобни проблеми и затова се опитвам да спазвам следните правила:
1. За Win9x никога не инсталирам FlexType и др. подобни ненужности.
-При инсталацията се избира не Typical, а Custom и там се определят регионалните настройки за България. За 95 може да се наложи да се сложи и Lang.exe от M$.
-За кирилизацията под DOS има доста добри решения, но аз обикновено ползвам Cyrdrv.com.
2. В Reginal Settings|Number|Decimal symbol заменям "," с "."
3. В Reginal Settings|Date|Short date style премахвам ""г.""
4. Гадното е, че на кирилица точката в NumPad се въвежда като запетая, независимо от зададеното в Reginal Settings|Number|Decimal symbol. Ако имате идея, как елегантно да се реши това, ще черпя.
Засега в програмите си, когато очаквам Real, а получа "." или "," ги преобразувам в DecimalSeparator
Напр.:
procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char);
begin
If Key=#13 then begin Key:=#0; Perform(CM_DialogKey,VK_TAB,0); end
else If (Key=',')or(Key='.') then Key:=DecimalSeparator // '.'
else If not(Key in [#3,#8,#22,'-','0'..'9']) then begin Key:=#0; Beep; end;
end;
5. За Delphi - ShortDateFormat е променлива!!! което означава, че стойността може не само да се чете, но и да се записва.
Така в FormShow напр. може да запишем:
ShortDateFormat:='DD.MM.YYYY';
и така ставаме независими от конкретните настройки на системата (вкл. "г.")
Тази промяна е валидна само за нашето приложение, което за другите приложения може и да е добре, но за съжаление и DataBase драйверите са други приложения.

reshenie ima makar i neznam kak ste stane na Delphi zashtoto ne sam se zanimaval s nego i neznam dali poddarzha Regular expresions

tochno takav problem se poluchi kogato servera na koito rabotim mu biaha promeneni regional setings zaradi index server-a
tapoto asp se startira s kakvito si reshi reginal setting v enviromenta
ta se nalozhi da si napisha edna funkciika za "normalizirane" na datata v format v koito az izkam
prosto pravia check s niakolko templates za regexp i koito machne mu pravia saotvetnoto konvertirane

P.S.
imam mnogo malko opit vav Windows programiraneto zashtoto osnovno sam pisal za *nix no kadeto ima regexp mozhe da se pravi kakvoto si iskash
dokolkoto imam niakakvi spomeni ot Delphi v tozi sluchai DB controlata ne triabva da e bound-nata kam datasource a da se chete ot nego i stoinostite da se stvat rachno i ruchno da se update-va posledvie saotvetnoto pole v bazata

Е, има и някои комбинации език - data engine които се справят малко по-добре например VB / ADO. Писах около три години едновременно разни потребителски системи на Delphi/BDE, VB/ADO и VC++/MFC, но от две години изоставих Delphi (не защотото не ми харесва езика, а има разни неудачия във визуалното му програмиране - поне до v.4), VC++ е доста трудно и нископродуктивно за моите цели и колкото и да е гаден език VB се указа много удачен, особено ако се работи в екип, в който има и по-начинаещи програмисти. За да не ме обвинявате в MS пристрастия, ще кажа че съм започнал от 1986 на TC, след това BC++ (от v.1 до 4.5) и имам реализирани доста голями проекти на C++. Моето мнение е - ако искате да ви е лесно и да не се занимавате с излишни проблеми - ползвайте VB и понесете подигравките на колегите си - все пак се работи предимно за пари и срока за реализация е доста важен.

няма нищо лошо в VB-то, но имам някакви спомени за проблеми точно с DAO/ADO и *г* в датата...
трябва да погледна пак (става въпрос за ASP VB скриптове)...

Delphi е по-добре когато разписваш собствени обекти (VB, поне до 6.0 нямаше разумна поддръжка на обекти създавани от програмиста) - това е удобно, много удобно.
БАЗИК-а е гаден език, който иска програмиста да е добър, обикновено по-добър отколкото за същото нещо на Delphi.

Обикновенно изборът Delphi/VB се прави от клиента - има хора които си мислят, че като се пише на БАЗИК те после ще оправят програмата...

Привет!
Аз пиша на Делфи 5 и до сега не съм имал този проблем. Постави полето като тип Datе и би трябвало да се получи. Ако не стане го направи Float (numeric) и пази датата като число, каквато е.
Тя по принцип се пази като дробно число, като дробната част е за час, минути ...
Пробвай