Hello HSE
I want to bring this project back to life. :biggrin:
I remember you mentioning that you had problems with the background colors of the right pane where the object information is displayed.
It would help me a lot if you could point out the problems you were having at the time so I can try to figure out what went wrong.
Thanks in advance for your help.
Biterider
Hi Biterider!
Quote from: Biterider on December 19, 2020, 06:50:58 PM
I want to bring this project back to life. :biggrin:
Fantastic :thumbsup:. That was missing :biggrin:
Quote from: Biterider on December 19, 2020, 06:50:58 PM
I remember you mentioning that you had problems with the background colors of the right pane where the object information is displayed.
If I remember well the main problem was I never could build the ObjAsm32 project. Then I can't see hardcoded colors in the "Dark" machine (what I see is useless :biggrin:), possibly because HighContrast.
But meanwhile, in "Light" machine, some ideas borned... :biggrin:
- I think that could be interesting to replace part of *.ini file with session's files, in the way that you can load a different setting in each project.
- If you open an specific browser configuration, still you can open another instance with a different configuration (for example the full list of objects)
- This is more complicated I think: When you open an specific project configuration the browser automatically show the ancestors of the project's objects.
But a project that build sound more than enough for now :thumbsup:
Regards. HSE.
Hi
I'm making some progress with this project. It seems to be more difficult than initially stated, as the OCX container is a bit tricky in 64-bit.
In particular, the COM dispatcher needs a completely new algorithm to process VARARG calls.
Known issues are:
- problems with namespaces introduced in C.1.1
- COM dispatching problems
- interfaces are not detected at all
- instabilities that lead to a GPF
In case anyone wants to play with it, here is the binary. :biggrin:
Regards, Biterider
Hi
I took a small step back in this project to check alternatives to the right object information pane.
I am currently using a web browser to render the content with all the complexities required to host it.
However, there is an alternative that could solve the problem and provide more flexibility: TextView. It has all the necessary formatting and interaction capabilities.
Making such a change is huge, but I think it's worth it. :biggrin:
Biterider
Hi Biterider!
Are you using hardcoded paths? I don't see nothing.
Regards, HSE.
Nice and tidy interface, but it doesn't find anything :sad:
Don't work at here, Windows 7 64-bit
A richedit can be usable for showing info.
A some help viewers use it, like mine TLWHViewRE for help 3 format.
Hi
Thank you all for the feedback. A new version is on the way.
Biterider
Hi
I finally managed to replace the browser-rendering engine with the TextView component and the result can be shown.
I decided to drop interface support for now and focus on the NameSpace issues. The strategy here is to treat all object declarations without an explicit NameSpace declaration as one class and with an explicit declaration as another class. In this way, "Primer" and "OA: Primer" are displayed as different things. It has not implemented that way yet, but it will be for the next release.
The interface support is broken because there are different declaration forms in the official Windows header files. Sometimes they are inconsistent and difficult to spot.
Thanks to the TextView control, I was able to put many links in the object page (blue text) to jump straight into the file on the line where the declaration is made. The code viewer / editor must be able to recognize the line number from the command line, such as NotePad ++. Unfortunately, RadAsm does not have this function, or I am not aware of it.
Here is a screenshot of the actual user interface, which is much cleaner and more consistent.
Biterider
Hi Biterider!
Look like directories are hardcoded, because that part of ini file never is readed. I found that :biggrin:. It's other thing :rolleyes:.
Regards, HSE.
Hi HSE
The paths to be searched are specified in the ini file and are not hard-coded. I've changed them very often to experiment with variations and deliberate errors to see how Explorer reacts without changing the actual objects.
The content of my ini file looks like this
[Setup]
Viewer="%ProgramFiles%\Notepad++\Notepad++.exe" "%s" -n%lu -lasm
ShowRedefinedMethods=1
ShowRedefinedVariables=0
Language=0
ScanOn=Start
Save=Yes
[Include]
0=.asm, .inc
;1=%OBJASM_PATH%\Projects\X\OA_ObjExplorer\Objects\
1=%OBJASM_PATH%\Code\Objects\
2=%OBJASM_PATH%\Code\Inc\Windows
[Exclude]
0=
1=%MASM32_PATH%\include\Windows.inc
2=%MASM32_PATH%\include\WinExtra.inc
In the include section I define on line "0" the file matching criteria, followed by the paths to explore.
The first one is commented out, which is my experimenting place. "1" is the usual location for the object repository and "2" where the interfaces should be. :rolleyes:
The exclude section follows the same rules.
Biterider
Biterider
ScanFile process all files.
I have to see why only the last (XWCollection) is showed in the tree.
Hello HSE
Thank you for your feedback. :thumbsup:
To better understand what is happening, I need more information. Maybe a screenshot or if you know in the code where something is going wrong would be good.
I haven't polished the code up yet, so it's likely that there are some big bugs there. :badgrin:
Biterider
Hi Biterider!
For sure I`m missing some update :biggrin:.
Yesterday I skipped pixelmap. Today updated that, and I see 3 objects.
In my next full update (last was only 5 days ago :biggrin:) I will see :thumbsup:
Thanks, HSE.
Hi
Here is a trial version of Object Explorer.
I found some irregularities and I want to know if this version (32 bit) works better.
COM interfaces are intentionally disabled.
Biterider
Hi Biterider!
Look good :thumbsup:
HSE