Проблема с принтером...

← →
KarlovAF (2002-06-06 15:55) [0]

Здравствуйте!
Есть вопрос:
мой проект работает как сервис NT от имени системы.
Я использую класс TPrinter для определения имени принтера, используемого по умолчанию:

var p: TPrinter; s: Integer; begin p := TPrinter.Create; s := p.PrinterIndex; {Здесь программа говорит, что нет определенного в системе принтера по умолчанию если запущена как сервис} p.Free; end;
А при инсталяции сервиса он запускается от Администратора, и все проходит успешно.
Подскажите, как решить эту проблему, или как определить имя принтера по умолчанию???
Заранее благодарен...

← →
Song (2002-06-06 20:38) [1]

Насколько мне помнится принтер по умолчанию указан в win.ini

← →
KarlovAF (2002-06-07 05:24) [2]

Нет там принтера :(((
Какие еще будут советы?

← →
Casee (2002-06-07 10:14) [3]

Только что разобрался с этой проблемой.
Заходишь в систему под Администратором, устанавливаешь принтер, ставишь его по умолчанию. Принтер прописывается в профиле администратора... Ферштейн?

← →
Casee (2002-06-07 10:19) [4]

О! Sorry, не понял вопрса. Перечитал еще раз и опять не понял.
Твой проект - Application? или Service? Где чего не работает?

← →
Севостьянов Игорь (2002-06-07 20:01) [5]

Ничего так не выйдет для службы
Точно сказать не могу, но по моему это из-за разных типов
Насколько я понимаю для TPrinter требуется TForm, а TService идет от TDataModule...

Да и какая собственно разница ?
По моему проще воспользоваться WinAPI для этого (что собственно и делает объект TPrinter). Можно выдрачиться и написать компонент TPrinterComp и положить его на TService (TDataModule).
Разбираться не вижу смысла. Посмотри как все это организовано в Printer.pas (EnumPrinters например API-шная фун-я) и сделай у себя в сервисе. Ну вообще проще воспользоваться API функциями
А для сервиса не срабатывает функция GetProfileString заложеная в Printer для определяния в NT Default принтера, для 95 используется EnumPrinters с флагом PRINTER_ENUM_DEFAULT

Так вот для NT (W2k) как я уже сказал есть функция
The GetProfileString function retrieves the string associated with the specified key in the given section of the Win.ini file. Windows NT/2000: Calls to profile functions may be mapped to the registry instead of to the initialization files. This mapping occurs when the initialization file and section are specified in the registry under the following keys: HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\IniFileMapping When the operation has been mapped, the GetProfileString function retrieves information from the registry, not from the initialization file; the change in the storage location has no effect on the function"s behavior. The Win32 profile functions (Get/WriteProfile*, Get/WritePrivateProfile*) use the following steps to locate initialization information: Look in the registry for the name of the initialization file, say MyFile.ini, under IniFileMapping: HKEY_LOCAL_MACHINE\Software\Microsoft\ Windows NT\CurrentVersion\IniFileMapping\myfile.ini Look for the section name specified by lpAppName. This will be a named value under myfile.ini, or a subkey of myfile.ini, or will not exist. If the section name specified by lpAppName is a named value under myfile.ini, then that value specifies where in the registry you will find the keys for the section. If the section name specified by lpAppName is a subkey of myfile.ini, then named values under that subkey specify where in the registry you will find the keys for the section. If the key you are looking for does not exist as a named value, then there will be an unnamed value (shown as <No Name>) that specifies the default location in the registry where you will find the key. If the section name specified by lpAppName does not exist as a named value or as a subkey under myfile.ini, then there will be an unnamed value (shown as <No Name>) under myfile.ini that specifies the default location in the registry where you will find the keys for the section. If there is no subkey for MyFile.ini, or if there is no entry for the section name, then look for the actual MyFile.ini on the disk and read its contents. When looking at values in the registry that specify other registry locations, there are several prefixes that change the behavior of the .ini file mapping: ! - this character forces all writes to go both to the registry and to the .ini file on disk. # - this character causes the registry value to be set to the value in the Windows 3.1 .ini file when a new user logs in for the first time after setup. @ - this character prevents any reads from going to the .ini file on disk if the requested data is not found in the registry. USR: - this prefix stands for HKEY_CURRENT_USER, and the text after the prefix is relative to that key. SYS: - this prefix stands for HKEY_LOCAL_MACHINE\SOFTWARE, and the text after the prefix is relative to that key.

Собственно можно ее изобразить так

function GetDefaultPrinterName: PChar; var Reg: TRegistry; begin Result := ""; Reg := TRegistry.Create; try with Reg do begin RootKey := HKEY_LOCAL_MACHINE; OpenKey("SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows", False) Result := PChar(ReadString("Device")); end; finally Reg.Free; end; end;

Так вот ReadString("Device") возвращает пусто, так как GetDataInfo выдает длину 0 т.к. не может найти этого ключа
Хочешь разбирайся (возможно что-то с доступом KEY_ACCESS_???)

Что тебе надо то ???

Все вопросы по мылу

Проблема с принтером... Найти похожие ветки