Jump to content


Photo

Paq Explorer Manager Task Force


  • Please log in to reply
15 replies to this topic

#1 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 14 June 2004 - 11:45 AM

Hi all this task is to prepare the PAQ Explorer Manager class to be used in PAQ Explorer. I'll try to be short and clear ^_^

*** Short History
This class needs to be changed cause it was previously developed under Borland CPP6 and the project migrated to Visual Studio .NET. Here some Borland's classes does not exists and we have to substitute them.

*** Why PAQExplorerManager
The PAQFiles library associates a file into the archive with a unique number and stop, so all files are saved togheter with no directory support.
The purpose of PAQExplorerManager class is to abstract the PAQFiles library and provide all functions to maintain the archive with directory support.

*** Current tasks
1) use exceptions instead of the current error handling
2) finish the defragmentation process (in parallel with the PAQFiles one)
3) convert the Borland Tree classes into something else available under .NET
I am currently working at tasks 1 and 2, Hymie the Control Robot is taking care of the task 3.

*** Purpose of this therad
Maintain an online diary and discussion place for development on this task.

Additional informations
The devpack part of PAQExplorer is not available for now under CVS. Hymie created a C++ Managed project and he's working on it.


Who wants to contribute is welcome; to commit changes to CVS just send them to me if you have not CVS write access

Exio
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#2 Hymie the Control Robot

Hymie the Control Robot

    Sergeant

  • Forum Members
  • PipPipPip
  • 50 posts

Posted 15 June 2004 - 09:37 AM

Exio, there's a bunch of std vectors in ExplorerManager. Do you know how they're handled memory wise in Managed C++, or do they behave exactly the same as normal (as in unmanaged C++) as long as they don't have the __gc keyword?

Also, I've converting a lot of the Utility::Strings that I'm coming across into .Net Strings, since that's what the GUI will use to call ExplorerManager. Do you think we should make a helper class of some kind to do conversion? The PAQFiles library uses the Utility String.

#3 Hymie the Control Robot

Hymie the Control Robot

    Sergeant

  • Forum Members
  • PipPipPip
  • 50 posts

Posted 15 June 2004 - 09:39 AM

Oh, BTW, for anybody else reading this topic, none of the devpacks are updated in CVS anymore. They are now available for download from this website.

Read this topic:

http://www.xcomufo.c...?showtopic=1789

The last message.

Unfortunately, the PAQExplorerNet project is still not in there yet.

#4 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 15 June 2004 - 01:16 PM

All STL classes are handled the same I think. I never tried to use them under C++ Managed.. the only way to know is to test.
Anyway as you said as long as the _gc keyword is not specified the compiler threats data as unmanaged. __gc is not needed when you declare a managed variable instead

Strings are really annoying things, I had lots of problems under Borland.
I suggest to keep Xenocide Strings in the PAQExplorerManager class and to convert them in the GUI classes, for coherence and portability.
If you already converted them, well... never mind that will not affect program functionality.
Writing an helper class is a good idea.

class StringConverter {
static Utility::String &getXenocideString(somestring);
static Utility::String &getXenocideString(const char *);
static somestring &getSomestring(Utility::String);
static somestring &getSomestring(const char *);
};

what do you think?
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#5 Hymie the Control Robot

Hymie the Control Robot

    Sergeant

  • Forum Members
  • PipPipPip
  • 50 posts

Posted 15 June 2004 - 06:47 PM

Strings are really annoying things, I had lots of problems under Borland.
I suggest to keep Xenocide Strings in the PAQExplorerManager class and to convert them in the GUI classes, for coherence and portability.
If you already converted them, well... never mind that will not affect program functionality.
Writing an helper class is a good idea.

class StringConverter {
  static Utility::String &getXenocideString(somestring);
  static Utility::String &getXenocideString(const char *);
  static somestring &getSomestring(Utility::String);
  static somestring &getSomestring(const char *);
};

what do you think?

That class definition looks good. The problem with keeping string conversions out of the PAQExplorerManager is that the TreeNode classes use .Net strings. We need to do conversion in cases where PAQExplorerManager uses tree nodes. The thing is, if we use the .Net TreeNode classes, PAQExplorerManager is *not* going to be portable. (especially when it's already a __gc class) I agree though that we should keep string conversions to a minimum. Places where tree nodes aren't used shouldn't need string conversion at all.

#6 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 15 June 2004 - 08:02 PM

Hymie, you cant change the Xenocide Strings as you then make PAQ Management library incompatible with Xenocide. The helper class is a very good idea, I would stick to that.

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#7 Hymie the Control Robot

Hymie the Control Robot

    Sergeant

  • Forum Members
  • PipPipPip
  • 50 posts

Posted 15 June 2004 - 08:30 PM

Hymie, you cant change the Xenocide Strings as you then make PAQ Management library incompatible with Xenocide. The helper class is a very good idea, I would stick to that.

Greetings
Red Knight

RK, we're not talking about changing the Xenocide string inside the PAQFiles library. We're talking about converting the strings to the .Net string inside the PAQExplorerManager, which is a part of the PAQExplorer. The PAQExplorerManager (which is a __gc class) would take .Net strings from the GUI, convert them to Xenocide strings, and call the PAQFiles classes with them.

Hope this clears it up.

#8 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 21 June 2004 - 06:13 AM

I just finished converting the old error codes into exceptions, I'm beginning to finish the defragmentation in the PAQ library
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#9 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 04 July 2004 - 01:40 PM

Hymie about the right click menu items in PAQ Explorer, I looked at the windows's explorer ones and I made them similar..
I used a single popup menu for the listview and modified it at run-time to provide different menu items when the user clicks on a file or on the white space. I used another menu for the treeview with only the directory functions.
Take inspiration from the windows's explorer and the last pre-release app.

If you're going to analize again which menu items are useful or not, I suggest you to build a list of all functions the used needs, group them by context (file, directory, cut&paste, additional informations, options and so on) and by importance or frequency of use.
(For example it's useless to add the "defragment" function in the popup.. it's used so rarely that can be easily accessed by the main menu)
Then you can build the menus basing on that schema and trying to make it as similar as possible to others fine managers, so the user will find easy to learn how to use it.

The .NET notation however calls "context menu" what I call "popup menu"
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#10 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 18 August 2004 - 12:43 PM

The defragmentation is completed and the code is updated on CVS

I have finished all the exams now and I have to prepare the thesis, so I spoke with my relator trying to unite the thesis with the work needed here (PAQ explorer). The result is that I am now working for a generic tree explorer, a program to explore and modify any tree structure (in this case the PAQ file system).
Red Knight and Hymie the Control Robot agreed about entrust to me the paq explorer again. I have to work alone cause the thesis is a personal work and I will be glad to share with you also the design documents I am preparing now, in the hope they will be useful for who wants to understand the way a programmer plans and develop his work, not only writes code and respect the standards of notation and compatibility.
The date for the thesis is 11 of October so the work will be ready before that date

Exio82
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#11 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 08 September 2004 - 02:45 AM

Hi guys
this is the preliminary architecture diagram of Tree Explorer, the component I'm developing for my thesis.
The diagram is incomplete (the low-level part is missing and the GUI isn't designed at all) and will surely change during the development process, anyway it's a good way to understand it's functionality.
I hope this will give you good ideas for designing the rest of the game too !

Attached Files


You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#12 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 08 September 2004 - 07:18 AM

Hey Exio what program are you using to make those drawings? I tend to use others programs, but most of the time I lose more time than prototyping on my blackboard, but I am open to embrace new technology :D as those graphics look very good.

Greetings
Red Knight
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#13 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 08 September 2004 - 08:23 AM

Hi RK!
I used Rational XDE, it's a Visual Studio .NET plugin which is very useful and also give the possibility to reverse engineer an already written project to see the diagrams. Unfortunately it's very heavy, they says 512M of RAM and on my system is always above 100M of used memory.
There are also smaller free tools like Poseidon, I think it is on sourceforge
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#14 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 19 September 2004 - 04:41 PM

Here's some class diagrams.
It displays the interface made available from the model to the rest of the world and between the test plugin and the model

Attached Files


You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei

#15 guyver6

guyver6

    Captain

  • Xenocide Programming Department
  • 599 posts

Posted 21 September 2004 - 02:45 AM

Hi there Exio

I see that you are working on some system that will not only handle PAQ files, but will be responsible for handling all files, am I right?

And what I'd like to know do you intend to manage also data from that files, or only provide an interface so it would be possible to handle data incoming from files in other way? The reason I ask is that I'm now in a phase in designing resources system for xenocide, that will allow to load/unload resources on request or basing on how long ago resource was "touched". Another thing is that Xerces for example handles io access internally (of course there's a possibility to pass a memory pointer so it can parse from memory) and how it's gonna be handled by that system of yours?

Guyver
Posted Image
Sourceforge: guyver6
LinkedIn: Andrzej Haczewski
"A good business idea, they say, can be explained in one sentence. Similarly, each program entity should have one clear purpose."

Join #xenocide at irc.freenode.net.

#16 exio82

exio82

    Programming Department

  • Xenocide Inactive
  • 61 posts

Posted 22 September 2004 - 03:49 AM

I see that you are working on some system that will not only handle PAQ files, but will be responsible for handling all files, am I right?

Yes it's a generic tree explorer.
There's a graphical interface that use a class library which use plugins, each one to access a specific tree structure. The class library is independent from the GUI so you can integrate it with everything you want (a client application for example).
You can access and modify the following things in a node:
- name
- content (it's dinamically loaded, so you can browse nodes without load it)
- a list of attributes with value (the name of the attribute is unique in the node)
- the relations with other nodes (parent-son)
The implementation is in C# and everything is an object (nodes, content, attributes etc.).

If you want to use the library in a C++ project beware that you must use C++ managed.

Another thing is that Xerces for example handles io access internally (of course there's a possibility to pass a memory pointer so it can parse from memory) and how it's gonna be handled by that system of yours?

For example when you access the "node.Content" property, you have a C# object. that object is created by the plugin, so when you write a plugin you have total control over the kind and the type of the object. In C# there are no memory pointers (they are masked by the framework), anyway in C++ managed I think there are ways to have a memory pointer pointing to some object data, or in the worst case you can call "object.ToString()" and access to the string memory pointer.

Did I answer your question? Are you thinking to use the class library to manage the resource tree?
You cannot teach something to someone. You can only help it to discover it within of himself - Galileo Galilei