工具制作进行中

Moen

自己的山寨BSC Cleanitol和DBPF的工具正在制作中，不知大家有什么建议呢

Cleaning Tool

Gordius（计划名）（下面这个图只是个模样而已，a fake application）

lrdcq

很好。。。

不过。。又是.NET啊。。我很用不惯这种程序
我没去学，不清楚是用什么编的（大概是C#么？）
我还是坚守我的C了。。。。

Moen

原帖由 lrdcq 于 2010-6-6 17:32 发表
很好。。。

不过。。又是.NET啊。。我很用不惯这种程序
我没去学，不清楚是用什么编的（大概是C#么？）
我还是坚守我的C了。。。。

C#

为什么不惯呢？

lrdcq

原帖由 Bobbi 于 2010-6-6 17:33 发表

C#

为什么不惯呢？

手上的framework经常缺文件，要我更新，
要不就程序爱崩溃
烦死了

其实我姐姐是学C#的，她倒劝我学C＃
不过我学C是做题用的，

总不至于解一道高等数学题还要写一个类吧。。（我有学C＋＋做题的同学这么做）

Moen

原帖由 lrdcq 于 2010-6-6 17:44 发表

手上的framework经常缺文件，要我更新，
要不就程序爱崩溃
烦死了

其实我姐姐是学C#的，她倒劝我学C＃
不过我学C是做题用的，

总不至于解一道高等数学题还要写一个类吧。。（我有学C＋＋做题的同学这么做） ...

崩溃其实是那些程序制作不严谨产生的（Datgen、FSHLib是例子）

OO在某些地方有用，有些没用

jackxu888

程序盲围观各路高手...

Moen

原帖由 jackxu888 于 2010-6-6 18:59 发表
程序盲围观各路高手...

记得你会一点Java呀

jackxu888

那个东西跟你这个不能比...
基本=0...

Moen

目前的Gordius XD

Moen

UI迟点弄，先把功能搞定了

暂时能显示图片文件（除了FSH以外）和LText、Lua、XML和SC4Path等的



我总算明白了为什么Reader不能正常显示LText文件里的中文了，嗨，那种解码方式= =

Moen

没Idea吗？


TGI的那三列要不要这样叫呢？


Directory文件的……System.Windows.Form.DataGrid控件似乎不是很好看= =

凍果

我覺得TGI保留英文名稱會好一點

jackxu888

+1

话说TGI的更改方式你最好改快捷一点
现有的reader很麻烦很麻烦...

rszxh

楼主是用OR_DAT.DLL解的dat包吗？
是的话，有劳把dll里的函数格式列一下吧(本人懒得解了)
例如
win32api "or_dat.dll" function input_parameter/type output_parameter/type

另外，最好把字体调成宋体
毕竟国人习惯于等距字符

[ 本帖最后由 rszxh 于 2010-7-7 07:54 编辑 ]

Moen

这样才好嘛

凍果——先保留一下
jaxkxu——Reader很麻烦也的确是一个我动手写这个程序的一个原因。 我曾考虑过如果是两次单击TGI值，那里变成一个文本框来修改TGI。这个应该很好XD（就像修改文件名那样）

说到修改TGI麻烦，Reader导入文件同样麻烦，它偏要一个原文件附加一个6行的TGI文件，太麻烦了。我还不如把这个TGI文件省下来，把原文件名设置成TTTTTTTT_GGGGGGGG_IIIIIIII.xxx这种格式
批量改文件名的软件很多，但是批量修改文件内容的软件很少……

rszxh——我是自行弄一个的。不过那个or_dat.dll，ilive有公布源代码[link]（1.3版）
字体方面，先考虑一下……

Moen

这样吧，单击TGI那三列，那里会变成个文本框来编辑XD


暂定的菜单



导入文件时读取TGI值的代码片段（那行正则表达式是关键）


东西越做越大，真是头疼啊

lrdcq

原帖由 Bobbi 于 2010-7-15 14:29 发表
东西越做越大，真是头疼啊

不用头疼了。。

我费了九牛二虎之力找到一本用C写win32程序的书，（就是讲windows.h的书）
那里面的东西看着更头痛的。。C#好多了

Moen

原帖由 lrdcq 于 2010-7-15 14:52 发表


不用头疼了。。

我费了九牛二虎之力找到一本用C写win32程序的书，（就是讲windows.h的书）
那里面的东西看着更头痛的。。C#好多了

Win32编程的确更头疼，因为要考虑到好多东西。（就防止内存泄漏就够麻烦了）

Moen

看来这东西是……

目光小小地转到CleaningTool那里
传统MessageBox的用户体验越来越不好，特别是“是与否”或“是、否与取消”。与其让用户选择就要回答一个问题，不如明确给出选择。于是乎这种对话框就会出现啦


这种对话框在Gordius里会用得更多，比如没有保存就关闭、插入一个文件提示是否压缩等等。XD

PS：在Windows7里，.Net Framework调用comctrl32.dll里的TaskDialog()函数会抛出EntryPointNotFoundException异常。在万恶的MFC里却能成功调用（#include "commctrl.h"）。微软究竟搞什么飞机啊（莫非是MAKEINRESOURCE()的问题？
用工具查了一下comctrl32.dll，里面的确没有TaskDialog()函数的入口点，但是MFC怎么调用的= =

-----------------------------------------------------------------------------------------
既然可以单击TGI来直接修改，那么压缩也能直接修改。和Reader相比，这样就更方便啦XD


-----------------------------------------------------------------------------------------
打算弄个好看点的主标签栏（TabControl太普通了，我打算模仿VS2008的那个）

还想着：
用户可以把项目列表隐藏在一边，整个界面主要是文件预览（这个Reader有）；也可以把文件预览窗格放在上下左右都行（Reader能，但目前做不到）；也可以把其中一个文件预览独立到主标签栏（Reader那个界面不可能做得到）
不过这种Dock处理太复杂了，得花点时间研究下

-----------------------------------------------------------------------------------------
家里的上网问题可能导致CleaningTool不能在暑假发布= =Gordius更要等好久（这项目可是很大的啊，也许明年吧）
不过花这么多时间编程，我的异世界还弄不弄（对于这个问题，好苦恼啊）

lrdcq

原帖由 Bobbi 于 2010-7-21 15:28 发表
看来这东西是……

目光小小地转到CleaningTool那里
传统MessageBox的用户体验越来越不好，特别是“是与否”或“是、否与取消”。与其让用户选择就要回答一个问题，不如明确给出选择。于是乎这种对话框就会出现啦
http:/ ...

我希望LZ在读入，使用文件这方面优化一下
我灰常受不了reader打开多大的文件就占多大的内存。。。
难道他就这么怕指针空悬么？？

[ 本帖最后由 lrdcq 于 2010-7-21 15:43 编辑 ]

Moen

原帖由 lrdcq 于 2010-7-21 15:42 发表

我希望LZ在读入，使用文件这方面优化一下
我灰常受不了reader打开多大的文件就占多大的内存。。。
难道他就这么怕指针空悬么？？

我这样想的：
读整个文件不是一次全部读取。一开始读每个项目，只读前20个字节。这样就能判断是否压缩和文件类型。等到调用的时候就把那个文件全部读取（不是所有）。
在Windows7的那个任务管理器看了下，把Simcity_2.dat打开都不过在60MB左右

我再想想还有没有更好的吧

（太依赖指针的确不好，C#都不允许直接用指针呢）

Moen

现在把核心工作放在内核……

先和Reader的内存占用做比较
Gordius在119MB左右


Reader 0.93就要217MB（1.0以后的这里会固定在45MB左右，看来私有区域很少用到耶！）



因为目前的一些类型的文件还没有弄好，所以读取Simcity_1.dat的时间在1.5s左右（如果都弄好的话，可以在0.5s左右了）

[ 本帖最后由 Bobbi 于 2010-8-2 22:14 编辑 ]

Moen

Part2的那个循环其实就是浪费时间的地方了