» FAQ по Borland C++ Builder

Здравствуйте!

Может ли кто-нибудь подсказать мне как на Builder'е программно создать источник данных ODBC? Это нужно для того, чтобы не настраивать программу вручную при переносе ее на другую машину.

Может у кого-нибудь есть уже готовый код? Или может кто-нибудь сталкивался с этим?

Заранее спасибо!

AvgustiN
Посмотри функцию SQLConfigDataSource.

Garrett
Спасибо! А Вы не могли бы подсказать можно ли с помощью этой функции создавать источник данных под "Опытными пользователями"?

AvgustiN
Не знаю.

Hi, all!
Проблема стара, как сам С++Билдер 2009.
Переезжаем с шестерки на 2009, появился наконец нужный нам компонент
Код простой, короткий:
AnsiString drtt;
drtt= (AnsiString)pFIBDSDistribut->FieldValues["HOST_ID"];
Сообщение об ошибке тоже простое, но не короткое:

E2015 Ambiguity between '_fastcall System::AnsiStringT<0>::AnsiStringT(const System::AnsiStringT<0> &) at c:\program files\codegear\rad studio\6.0\includevcl\dstring.h:358' and '_fastcall System::AnsiStringT<0>::AnsiStringT(const wchar_t *,int) at c:\program files\codegear\rad studio\6.0\include\vcl\dstring.h:392'
Возникает вопрос, а какого собственно возникает не однозначность и как собственно её избежать? В данном конкретном случае.
И поскольку я уж зашел в этот топик, то задам ещё вопрос по строкам, тем кто уже переехал на 2009. Правильно, наверное, будет заменить все AnsiString в проектах на что-то типа String? Оно вроде как по дефолту юникодное?

AnGo
Я заменил все AnsiString на UnicodeString.
Только есть засада, c_str() возвращает char*, а для wchar_t* нужно вызывать w_str().
Из базы в одной проге читаю так
WideString name = ADOQuery2->FieldByName("user_name")->AsWideString;

AnGo
Насколько я понимаю - неоднозначность из-за того что вызывается приведение типа к AnsiString, соответственно компилятор смотрит какой из конструкторов AnsiString использовать для приведения типа. Но то что возвращает pFIBDSDistribut->FieldValues["HOST_ID"] подходит как параметр для обоих конструкторов.

Посмотри есть ли функции из разряда как Garrett написал - ADOQuery2->FieldByName("user_name")->AsWideString - без неявных преобразований.

AnGo
за подобное приведение типов и в обычном С++ руки отбивать надо. Что вам мешает использовать более стандартные конструкции?

Добрый вечер, не подскажите такая проблема поставил 2009 и началось, когда та же программа работала в 2007 на ура, но не в этом суть, не могу понять как мне перегнать теперь из wchar_t в обычный char:
strcpy(buf_send,Edit1->Text.c_str()) в 2007 работает все на ура, в 2009 вызывает ошибку Cannot convert 'wchar_t*' to 'const char*'
Как решить проблему?

Mifonix
Помню, что в первых версиях RS2009 c_str() у UnicodeString возвращал char*, а w_str() соответственно wchar_t*.
Я тогда переводил одну свою старую программу на юникод и это сильно меня напрягало. И думал с какого бодуна они это сделали.
Сейчас заглянул в последнюю справку, теперь оба возвращают wchar_t*, причём я думаю, что w_str() скоро умрёт.
Так что понятно, почему у тебя это не работает. Поэтому есть 2 решения:
[no]1.
UnicodeString s = Edit1->Text;
или
WideString s = Edit1->Text;

2.
#include <memory>

int Size = Edit1->GetTextLen() + 1;
std::auto_ptr<wchar_t> Buffer(new wchar_t[Size]);
Edit1->GetTextBuf(Buffer.get(),Size);
[/no]

А че WideCharToString - отменили чтоли?
Такое впечатление что только с выходом 2009 версии все только вот и узнали о расширеном наборе символов.

Garrett
Kott

Спасибо за советы решения проблемы!

Добавлено:
Оказывается что бы перегнать в обычный char* в 2009 надо использовать не c_str(), а t_str(), и все работает!!!

Госопда вопрос почти в тему предыдущему..

Консольное приложение без vcl, стандартный метод вывода cout << "Какая либо строка": так вот как вывести на консоль эту какую-либо строку в юникоде?

Meister_Floh
Юникодные литералы пишутся так: L"Какая либо строка" .

Garrett

Сори могет сапсем туп.. Т. е. должно выглядеть вот так: cout << L"Какая либо строка"; ???

Чего мучится то? не проще ли ВЗЯТЬ и ПРОВЕРИТЬ?

Kott
Да проверил уже.. не работает.. В принципе понял, что для того, чтоб был юникод надо строку делать типа wchar_t* только вот трабла в стандартном ostream описано только cout << const char * .. Вот сижу думаю теперь как бы это его в консоль юникод запихнуть..

Добавлено:
Как я понял вопрос достаточно глобален: Unicode в Console Application в RAD Studio 2009 -> Русские символы в консоли...

Meister_Floh
Надо так, но не знаю, будет работать или нет
wcout << L"Какая либо строка";
Если не поможет, то мучить фасеты, или попробовать как-то по-другому.

И если не секрет, зачем тебе юникод в консоли?
Может тебе просто поможет команда chcp?

Добавлено:

Если вопрос только в том, чтобы увидеть русские буквы в консоли, то надо так
#include <iostream>
#include "windows.h"

SetConsoleOutputCP(1251);
std::cout << "Привет\n";

Только билдер не может показывать русские буквы в консоли(по крайней мере у меня не выходят). Но при запуске программы из-под ФАРа, ты увидишь разницу между программами с и без SetConsoleOutputCP(1251);

Если надо ещё и вводить с консоли в кодировке Windows, то перед cin вызови SetConsoleCP(1251);

Garrett
Ну подвижка вроде есть, но не до конца.. Консоль по умолчанию в висте 866 - вот отсель похоже и траблы и ноги растут.. Руских букв у меня как не было так и нет, но поле для экспериментов огромное

Добавлено:
Решилось!! Хотя и решение жутко кривое.. В параметрах компилятора поставил 866 страницу..

Meister_Floh
Прочитай мой предыдущий пост до КОНЦА! Зачем менять настройки компилятора, когда можно вызвать SetConsoleOutputCP(1251); ?

Garrett
Дык прочитал Не работает так.. Хотя может это фича висты а виртуалку xp подымать неохота..

Meister_Floh
Ты запускал полученный exe-файл вручную из под командной строки или ФАРа ? (Не из среды).

Garrett
totalcommander->cmd->project1

С заменой кодовой страницы для острим на 1251 - крякозяблы как в выводе строки так и в кирилистических именах директорий

С компиляцией с кодовой страницей 866 - все гут..

Кстати твоя идея с wcout << L"Tnglish string" << "Русская строка"
вывод в юникоде, но.. ангельская строка читабельна, кирилистическая со знаками вопроса.. Таким образом сделал предположение, что консоль висты НЕ ПОДДЕРЖИВАЕТ юникод.. В чем и убедился, когда посмотрел по GetConsoleCP() кодовую страницу, она оказалась как уже понятно 866...

Meister_Floh
У меня под ХР кодовая страница меняется. Запускал файл ФАРом. На Висту многие вешают все смертные грехи, но я с ней работал немного, основная претензия - медлительность, всё другое у меня работало как и в ХР.
Я надеюсь, что когда ты компилировал с SetConsoleOutputCP(1251); ты в настройках компилятора отключал свои 866 ?

Garrett
Само собой отключал.. Кстати заметил фичу, если раз проставил кодовую страницу, потому убрать ее на пустую строку удается, только при помощи .opset, в котором эта опция пустая

Meister_Floh
У меня и у сотрудников к сожалению нет Висты, чтобы проверить самому... Завтра попробую на Вин2003, но думаю, что и там всё будет ОК. И еще киньте мне в ПМ свой мейл, я соберу 2 ехе-файла и вышлю сегодня или завтра вам, попробуете мои файлы на своей висте.

Garrett
а я в ответ свой исходник Вам кину..

Meister_Floh
Послал.

А я в ответ выслал 2 сккриншота.. Через часик вышлю свой исходник и скомпиленую версию..

Meister Floh
Отвечу здесь, может и другим будет интересно.
Ответ, кстати, кроется в последнем предложении описания SetConsoleOutputCP в MSDN.
However, if the current font is a raster font, SetConsoleOutputCP does not affect how extended characters are displayed.
Т.е. запустив консоль (пуск-выполнить-cmd) и поменяв в свойствах консоли шрифт с "Raster fonts" на "Lucida Console" ты увидишь, что мои проги(и н-е твои) удивительным образом стали работать!!!