Да, вот еще - нарыл класс, который реализует на API всю функциональность CommonDialogControl. Приглашаю тебя его юзать. Иначе тебе прийдется всех юзеров обязать устанавливать у себя comdlg32.ocx, что не есть гуд ;)
Вид для печати
Да, вот еще - нарыл класс, который реализует на API всю функциональность CommonDialogControl. Приглашаю тебя его юзать. Иначе тебе прийдется всех юзеров обязать устанавливать у себя comdlg32.ocx, что не есть гуд ;)
а можно ещё использовать стандартный компонент TreeView. и динамически ничего не надо создавать, и группировки можно делать многоуровневые, как захочешь
Да, а кроме нее в некоторых местах читаются свойства Dialog.FileNameЦитата:
Сообщение от Odrick
Я бы с радостью, но компонент TreeView находится в Microsoft Windows Common Controls 6.0, а это еще одна библиотека, которой опять у кого-то не окажется! Но, впринципе, если у меня получиться, я сделаю навигацию по группам параметров и самим параметрам в виде дерева. Значения параметров будут задаваться так же, как сейчас (через комбобокс).Цитата:
Сообщение от SMT
В последней выложенной версии 1.2 ввел отсичение из записи базы параметров, которые отсутствуют в загруженном ini. Это полезная фишка, позволяющая делать одну опщую запись для нескольких версий эмулятора (в параметре записи SUPPORT перечисляются номера поддерживаемых версий) но в базе я пока ее не использовал (нужно проанализировать базу и выявить возможности обьединения версий).
С самых начальных.Цитата:
Сообщение от icebear
Если не в курсе - "EXE" которые делает VB - являются байт-кодом бейсика, который исполняет msvbm.60.dll
>verinfo MSVBVM60.DLL
company: Microsoft Corporation
file description: Visual Basic Virtual Machine
file version: 6.00.9690
internal name: MSVBVM60.DLL
legal copyright: Copyright c 1987-2000 Microsoft Corp.
legal trademarks: MicrosoftR is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Co
ration
original filename:
product name: Visual Basic
product version: 6.00.9690
comments: September 3, 2002
Она может не оказаться только у любителей windows 95.Цитата:
Сообщение от Dr.Lion/RSM
Ага. Ну тогда можеш для этого ввести переменную для хранения текущего имени, или все же пользовать тот класс, что я выложил выше. Пользовать его проще-простого. Почти ничем не отличается от CommonDialogControl. Нужно его добавить в проект и использовать можно примерно так:Цитата:
Сообщение от Dr.Lion/RSM
Пример тоже выкладываю.Код:Option Explicit
Dim cdlg As New CommonDlg
Private Sub Command1_Click()
cdlg.hWndOwner = Me.hWnd
cdlg.FileName = ""
cdlg.DefaultExt = "ini"
cdlg.InitDir = ""
cdlg.Filter = "Файлы ini|*.ini|Все файлы|*.*"
cdlg.DialogTitle = "Выбор файла"
cdlg.Flags = dhFileOpenConstants.cdlOFNReadOnly
cdlg.ShowOpen
End Sub
И на основании этого вы делаете вывод, что VB имеет некую Виртуальную машину? :D Повторюсь еще раз: давайте тогда называть виртуальной машиной, например, gdi32.dll. Почему бы нет? Тоже имеет набор функций, которые используют все програмы под виндой ;)Цитата:
Сообщение от Raider
Извините, но это чушь ;) Exe на то и exe, что это исполняемый код. И по барабану чем он скомпилен. Повторюсь - в msvbm.60.dll лежат всего лиш стандартные VB-шные функции и серверы com-объектов. Я работаю на VB уже 8 лет, так что... Не верите мне, зайдите на http://bbs.vbstreets.ru/viewforum.php?f=1 и задайте вопрос, что ж собой являет exe, скомпиленый в VB ;)Цитата:
Сообщение от Raider
Ну-ну. Напишите смеха ради програмульку с деревом, а потом переустановите винду. И на чистой винде попробуйте ее запустить ;)Цитата:
Сообщение от Raider
Наконец-то мне объяснили, как использовать этот аналог Common Dialog Control. Буду внедрять в следующую версию 1.3, надеюсь это уберет зависимость программы от comdlg32.ocx! В новой версии так же планируется расширить и реорганизовать базу версий, возможно немного изменить интерфейс. Выход новой версии 1.3, которая будет вполне полноценной и пригодной для широкого использования, намечен на первую половину следующей недели. А теперь пара вопросов:Цитата:
Сообщение от Odrick
Так стоит ли мне мучаться с деревьями, дабы улучшить навигацию по параметрам, или нет, потому что это может породить новые проблемы и выход полной стабильной версии опять задержится?
Как вы относитесь к подобранной мной иконке? Может ее нужно сменить на другую? Лично мне эта очень нравиться и вполне соответствует по смыслу самой программе.
Cooper пообещал на этих выходных разместить на нашем сайте realsoftmakers.nm.ru последнюю версию (на данный момент 1.2) UConfig, так что заходите и качайте!
Всегда пожалуста :)Цитата:
Сообщение от Dr.Lion/RSM
Точно уберет.Цитата:
Сообщение от Dr.Lion/RSM
ИМХО дерево не нужно. Красиво, но причина ясна. Лучше простой лист-бокс слева с списком главных разделов эмуля. Рядом - список веток выбранного раздела. Еще правее - список значений. Все это не комбиками, а именно лист-боксами. Так будет нагляднее, как по мне. А там можно заморочится и с динамическими контролами, когда логика будет отлажена ;)Цитата:
Сообщение от Dr.Lion/RSM
Раньше всегда юзал US с фильтром double (не люблю размытие), на старом мониторе стояло разрешение 800х600. Сейчас сменил монитор на большую TFT девятнашку, приходится ставить 1280х1024, и фильтр double стал неюзабелен - получается окошко в четверть экрана. Может, стоит добавить фильтры triple/quadro?:)
Про exe в курсе. Оказывается мелкомягкие у сантехников не только пол-явы украли :) Только вот не уверен я, что компилится это всё в байт-код.Цитата:
Сообщение от Raider
Shiru, слишком просто. я подумаю, как можно сделать поинтереснее для больших разрешений... сам я, в основном, смотрю в окне. на столе тоже 1280x1024
а зачем тогда они преподносили компиляцию в native-код, появившуюся в 5-й версии, как преогромнейшее достижение? :) шутка раньше была, насчёт байт-кода?Цитата:
Сообщение от icebear
Точно не компилится ;) Иначе была бы возможность "распаковать" exe-шник в удобоваримый листинг программы. А это, естественно, невозможно. Так как и невозможно увидеть имена переменных, как это было бы в случае с байт-кодом. Был в свое время распаковщик для VB5, но работал он просто вычитывая обращения к функциям из msvbm50.dll и на основании этого строил некий листинг. Но совершенно неудобоваримый с именами функций типа func1, переменных типа var1 и т.д. По моему даже размерности не вытягивал - везде Variant лепил. А для VB6 и того нет, есстессно. Так что не байт-код, а все же полноценный исполнимый код ;)Цитата:
Сообщение от icebear
вовсе нет, преобразование не обязано быть взаимно однозначным, оптимизатор даже может пройтись по байт-кодуЦитата:
Сообщение от Odrick
зы бывает байт-код похуже асма. такую виртуальную машину изобредут, вовек не разгадаешь :)
Каюсь-каюсь :) Только что ради интереса порылся в и-нете по поводу вариантов компиляции приложений VB - действительно до 5-й версии проекты компилились в некий p-код, который и был тем самым пресловутым байт-кодом. Начиная с 5-й версии VB компиляция происходит в Native код (код комманд процессора), но возможность компиляции в p-код сохранена. Ндя... Проработав 8 лет на VB6 о таком моменте в истории VB не знал :) А по умолчанию проекты компилятся в Native, есстессно... Приношу извинения :)
Я не в курсе, как это устроено в VB, только знаю, что язык это интерпретируемый. А понятия "интерпретация" и "байт-код" у меня как-то не вяжутся. Либо мои знания о VB вообще нифига не стоят :) Но "виртуальная машина VB" звучит как-то необычно.Цитата:
Сообщение от SMT
Нет. После компиляции в Native-код никакой интерпритации уже не происходит. Справка: Native-код - это набор команд процессора, струппированные в файл плюс парочка управляющих процедур. Какая уж тут интерпритация? ;) Ладно, по-моему пора с этим уже заканчивать, а то перерастает в флейм... Если кому интересна специфика работы VB, это можно выяснить отдельно ;) Напоследок только хочу сказать, что с выходом 5-й версии, VB превратился действительно в мощную и полноценную среду разработки. По быстродейтсвию код VB стоит сразу после VC (в некоторых задачах, а в некоторых превышает, а еще в некоторых остается далеко позади ;)). Так что ругать VB сейчас уже просто не за что :)Цитата:
Сообщение от icebear
программа компилируется в байт-код, который потом интерпретируется, так как не может напрямую выполняться процессоромЦитата:
Сообщение от icebear
в MSDN и не таких сочетаний насмотришься...Цитата:
Сообщение от icebear
неудивительно, ведь у всех ms-компиляторов общий back-endЦитата:
Сообщение от Odrick
компилятор не за что, а сам язык корявыйЦитата:
Сообщение от Odrick
Не буду спорить - устал уже ;) Это обсуждалось тысячи раз на разных форумах. И подобных заявлений я слышал уже море. Но на просьбу ответить, почему же он корявый ни одного вразумительного ответа я не услышал. Возможно, это связано со стереотипом, установленным в СНГ еще со времен СССР. По старой памяти о Basic'ах, которыми нас запихивали в школе ;) VB сейчас имеет с ними ооочень мало общего. Возможно, по причине не очень хорошего его знания и понимания.Цитата:
Сообщение от SMT
ну так покажи, как описать маасив вместе с его заполнением, например
char x[4] = { 0,1,2,3 };
или
var x: array [1..4] of char = (1,2,3,4);
;) Да, это невозможно. Только вот зачем? Мне удобнее и понятнее вначале описать массив, а потом уго заполнять. Это всего лиш вопрос удобства и привычки и не может быть камнем в огород VB :) С таким же успехом я могу спросить у любителя Pascal как красиво сделать цикл с произвольным шагом? На что он мне резонно ответит, что красивой конструкции в языке нет, но сделать можно и ему так удобнее и читабельнее. С чем я, конечно же, соглашусь. Что еще? ;)
всё так, только таких камней целый огород, да и паскаль тоже ацтой :)
Ну что ж ты так категоричен? :) Паскаль хороший язык, Бейсик хороший язык, С хороший язык. Все зависит только от привычки. Тебе удобнее так - все остальное тебе будет казаться ацтоем. А при современном уровне развития компиляторов на ресурсоемкость и быстродействие практически никак не сказывается среда разработки. Сказываются только кривые руки и багаж знаний ;)
а ассемблер какой замечательный язык!
А то! Конечно замечательный. Уверен, найдутся тысячи людей, готовых закидать гнилыми помидорами программистов на языках высокого уровня ;)
Jeffie, вообще-то у группы RSM есть собственная страничка в инете - http://realsoftmakers.nm.ru. Поэтому давай ссылку на прогу-конфигуратор на сайте сценерджи именно туда, а не на форум. Автору будет приятней вдвойне :)
2Модеры: сорри, за оффтоп.
Пофиксил.Цитата:
Сообщение от Cooper^RSM^P7S
сабж! в именах файлов букву 'b' забыл, но с sf бороться невозможно - что упало, то пропало :(
Код:version 0.31b 24 aug 2005
! atapi: sense key not placed into error register on ATAPI error
! atapi: fixed bug in ATAPI commands, that don't return data block
! atapi: fixed bug with DRQ on end of ATAPI data block
! gs: "save mod" was disabled since 0.28b [fb TJ]
! fixed bug in window size after leaving fullscreen [fb Tj]
+ new funny led shows R/W/X dynamic in spectrum memory [sb Raider]
+ keyboard shortcuts in windowed mode: Alt-1, Alt-2, Alt-3
+ 4x scale video filter [sb Shiru Otaku] (set minres=1024 to avoid 1280x960)
+ shows condition hit and jp/ret/call direction in trace window [sb Dexus]
+ monitor: Alt-F9 shows only ray-painted screen area
+ monitor: Alt-S cycles through watches / screen dump / ray-painted
- monitor: mon.render hotkey is deleted (as obsolete)
* monitor: detection internal loop exit when tracing loop on F8 [sb Dexus]
+ monitor: fill memory with pattern [sb Raider]
* FDD & FDC code comletely rewritten, bugs may appear
! when saving disk image, prefer original format as default, not TRD
! CacheVox works fine with [BETA128]Fast=0. no other emul can handle this yet
! better WD1793 sector write emulation (overwrite old gap and data AM)
+ monitor: more fields in beta128 panel (see docs)
@ visual ini-file editor available at http://realsoftmakers.nm.ru/RSM.files/download.htm
SMT, небольшое примечание по поводу "стрелок" - во-первых цвет красный на фиолетовом фоне не очень хорошо видно, во-вторых - можно было бы показывать КУДА пойдет этот переход, типа стрелочкой влево? Тогда сразу будет удобно видеть куда уйдет, если в пределах экрана, или даже если за пределами - то проскрулял и быстро нашел то место, которое надо. Вертикально "вытягивать" стрелку через все строки промежуточные - наверно не надо, а вот точка перехода была бы кстати :)
И еще - насчет текущего отрендеренного экрана - нельзя ли сделать микроградиентика в той точке, где находится луч?
т.е. например в конкретно той точке где находится луч - на 8 единичек яркость выше...предыдущие - вплоть до 0...
это если курсор стоит на правом поле. а если на левом, то фон - белый. сразу не хотел менять цвет в зависимости от положения курсора. надо, всё-таки, поменятьЦитата:
Сообщение от Dexus
это сложно. рисовалки во всех видеорежимах берут буфер "байт пикселей на байт аттрибутов". а alf-f9 лишь подготавливает закрашенный после луча буфер и вызывает рисовалку от текущего видеофильтра, придётся менять все видеофильтры. да и на экране нет точки луча, контроллер читает сразу целый байт из озу, поэтому сейчас корректнее :)Цитата:
Сообщение от Dexus
по просьбе Ordick'a выкладываются редкие РОМы
О, пасибочки ;)
Ок согласен по байту корректнее. Но по-моему не совсем корректно то, что ПОСЛЕ луча нету предыдущего кадра... ведь он реально там остается видимый.. и именно от того появляются эффекты "скошенности" при неудачно сделанных скроллах, или частичного пропадания спрайтов на некоторых схемах, где синхроимпульс начинается ровно с paper'а.Цитата:
Сообщение от SMT
Было бы более удобно видеть не только УЖЕ нарисованное (да и голубой фон базовый как то немного страннен), но и то что ЕЩЕ не стерто. ХОтя бы каким нибудь яркостным переходом... Типа эмуляция "гашения" люминофоров. То что только что прорисовано - ярче. то что самое старое (перед лучем) - еле видимое... или за лучем градиент такой... начиная от очень темного (33% допустим, сразу после байта который рисует луч), постепенно до 100%.. строчек на 10 размазать... Главное чтобы граница наглядная была между рпошлым кадром и текущим..
Извиняюсь что опять озвучил свою мысль :)
Правда это наверно сложно будет сделать. Зато реалистично и
фон такой, чтобы с фоном программы редко совпадало. градиенты невозможны с текущей архитектурой видео, она расчитана на любой видеорежим (начиная от 8 бит, именно в 8 бит работает фильтр gdi, включенный по умолчанию). можно использовать лишь 16 спектрумовских цветов (отладчик ведь может и в 640x480x8 работать). УЖЕ нарисованное было видно в прошлых версиях :) но тут же на форуме просили сделать рисование до луча. "скосы" как раз будут видны, когда луч дорисует кадр. а скос между "до луча" и "после луча" не должно быть видно, это нормально. разве что я могу сделать так: не стирать пиксели после луча, а ставить их синими на циановом фоне, тогда будет видно и старое изображение (без цветов), и новое. бордюры и мультиколоры не будут видны, поэтому ценность такого изображения сомнительна
то есть можно, конечно, эти функции отладчика сделать зависимыми от режима экрана, но честно говоря, написание функций под все битности и скейлы в разных видеофильтрах меня уже достало. так что, раз уж всё равно взялся делать альтернативную ветку, запросто можешь подрисовать и градиенты по вкусу :)
Привет !
2SMT:
Кажется, в новом движке FDD есть глюк - BestView при отключенном No Delays не хочет ничего загрузить - появляется желтый border. (при включенном No Delays - все O.K.)
Еще заметил, что в TV Emulation (также в Frame Resamper, но там это не мешает) нельзя уже включить опцию VSync (это появилось в US v0.30, ранее было O.K.) Из-за того анимация выглядит хуже.
А еще мне не нравится следующее. Если эмулятор работает в полноэкранном режиме (driver=ddraw), то при нажатии Alt+F1 окно настроек получается громадного размера и не умещается на экран, что затрудняет навигацию по настройкам. К части контролов вообще невозможно добраться. Было бы полезно на момент входа по Alt+F1 переводить эмулятор в GUI режим. Я работаю при разрешении 1024x768, а какое там разрешение выставляет эмуль в полноэкранном режиме я не знаю.
понятно, буду доделыватьЦитата:
Сообщение от Kubas
да, на радеонах vsync в оверлее выглядит ужасно (сильно тормозит). сегодня поставил 6600GT - там действительно нужен vsync. ну что ж, буду подгонять под моё сегодняшнее железо :)Цитата:
Сообщение от Kubas
но ведь minres=480 по умолчанию в ini включен...Цитата:
Сообщение от Dr.Lion/RSM
Это глюк не движка фдд, а бествью, у которого от чумовой скорости диска и вгшки крыша едет =) А вообще конечно бествью давно пора под 3д13 делать, по понятным причинам.Цитата:
Сообщение от Kubas