I have received 10 PAS files. All the lines in these 10 files starts in column 1. NO indentation at all.
Biggest file is 2548 lines.
Now I wonder: Is there an OPTION in my Delphi 7 Enterprise (running on XP sp 3) to automate that indentation to increase readability (at least for me):
IF not I plan to scan through the files and when BEGIN, THEN, ELSE, CASE, END etc. (where indentation will be natural) is met, I will (if necessary) do a manually indentation. (But it is smarter letting Delphi do it).
you can use CnPack
http://www.cnpack.org/showlist.php?id=39&lang=en
it has (among a lot of features) a Code Formatting Wizard and some other nifty features to enchance the IDE
A bit of history... I have 3 systems that I spend time on, a DOS 6.22 system, a Windows 95 system, and a modern Windows 7 (64-bit) system. When I upgraded to Win7-64, some of my favorite command line utilities stopped working, so I decided to re-write them myself. The only 2 compilers I have are Borland Turbo C++ 3.0 and Visual Studio 2008, and they worked fine for building 2 versions, a DOS 16-bit, and a Windows 7 32-bit (could have built 64-bit too, I guess.) The problem came with my Win95 system. The DOS version works fine there, but since I spent the time to support LFNs in the Win7 build, I wanted it with my Win95 system. So, after a lot of research, I found and purchased Visual Studio 6 (last one with Win95 support according to what I researched,) copied the code over (had to rewrite sections, of course,) and it compiled just fine, and works :)
The problem occurred the next time I had to boot my Win95 system in DOS mode. The program stopped working (of course,) because Win95 wasn't loaded. I don't really want to have 2 copies of the program installed (needing 2 different file names,) so I was hoping there was a way to link the 2 versions together into one file. If I execute it in DOS, instead of it saying it requires windows, it would just jump to the DOS section of the program. That way, it would be a single program, with LFN support if Win95 is loaded, and without if Win95 isn't loaded. Since the Win95 version also works fine in Win7-64, it would probably also produce a single version that works on all 3 systems (which would be an added bonus.)
I did some web searches, and couldn't find anything germane to what I'm looking for. So I have no idea if it is even possible. I may have to get yet another compiler, but considering how old it would have to be, I could probably afford it. My web searches did result in information that leads me to believe that it "should" be possible, though. It would just require a different exe header than the one Windows compilers put in. It may require that I re-write the DOS version for 32-bit and use a DOS extender (for protected mode, assuming I can't find a way to include it in the file itself.) That would be acceptable (though not ideal.) I would much rather have 16-bit code in the DOS section, and 32-bit code in the Windows section (for the most compatibility.)
Does anyone have any information about something like this? If you could just point me in the right direction it would be greatly appreciated.
I don't know if it has been continued in Windows 7 executables, but back in Win95 the executable (EXE) actually had two entry points -- one "normal" one that DOS would find, and a second one that Windows would use. The DOS entry point was usually a very simple default that would just print "This is a Windows program" and exit. You can actually override this default, and have the linker use your own code, however it is very limited.
What I'd recommend doing is add logic to your DOS 6.22 version (e.g. "sed") that would check the OS level & if it meets the right criteria, pass the parameters along to a second executable (e.g. "sedx") that uses features from the "newer" OS.
The documentation for Visual Studio 6 describes the /STUB option here, simply point this at the DOS version of your program.
I don't have VS6 handy, so I can't be too specific, but in the project settings GUI, there should be an "additional options" setting in the linker section.
Well the answer is the /stub option in the Linker you are using for your Windows code. Some additional information for anyone who finds the question later.... I had to do several days of web searches to find that there doesn't appear to be another answer to my particular problem.
Stub requires that the DOS mode executable have a header of at least 40 bytes. After fighting with multiple compilers that "DO" give you a header of the right size (Borland Turbo C++ won't,) and not being able to convert my code, I had to get sneaky/fancy. BTW - Visual C 1.52c (last Visual C that supports DOS,) will make a correct header, as will Open WatCom.
If you are faces with the same issue I was - the compiler you used won't make the correct size header, and your code is too compiler specific to convert easily, you can do what I ended up doing. I used Open WatCom to write a tiny ("Hello World") Windows program using my exe with the short (Borland created,) header as the stub. Open WatCom will adjust the header automatically. I then used a Hex Editor to read the header information to get the ending address of the stub and a partial file copier to copy only that part of the program to a file I named "stub.exe" (stripping of the Windows code.) Using the same Hex Editor I zeroed out the PE pointer in the header. I now had a working DOS exe that would also work as a stub. Took my stub to my Windows compiler, and linked it in. It works great, all features fully realized :)
FYI - Information needed to strip the Windows portion and zero the PE pointer.
first byte is offset 0 (of course, but some people may not realize that, and think it's byte 1.) Also remember, that most Hex Editors (by their very name,) are giving you numbers in hexadecimal format.
offset 2 & 3, number of bytes in the last block of the DOS portion of the file in low byte - high byte format. That is, offset 2 is low, 3 is high. So take them, reverse them, and you will get a number from 0 - 511 (0 - 1ff in hex.) 0 means the entire block of 512 (200 in hex) bytes is used.
offset 4 & 5 (again in low/high format,) is the number of 512 (200 in hex) byte block in the DOS portion. Remember to reverse the number, and that the last block may only be a partial block. So, subtract one, multiply by 512 (200 hex,) add the number from 2-3, and you have how many bytes are in the DOS portion. Since you are starting from 0, subtract 1, and you now know to only copy bytes 0 - "whatever the total is" to your stub exe.
offset 60-61 (hex 3C-3D) is the pointer to the start of the PE (or Portable Executable,) portion of the code (the part that Windows jumps to.) It should be just past (mine was padded with a few zeroes,) the end of the DOS portion of the code. This isn't important at this time, as we are just turning those into 0's anyway (the PE portion has been stripped.) You can use this as confirmation that you have the correct "end of DOS" offset selected though.
The tools I used are:
Open WatCom at http://www.openwatcom.org/index.php/Main_Page
and
Part Copy at http://www.virtualobjectives.com.au/utilitiesprogs/partcopy.htm
I have no idea where to find the Hex Editor I used. I used CEdit, a DOS program I really like, but have been unable to find on the net. Have to use DOSBox with it as Win7 won't run it, though. There are probably other compilers that do the same thing, and probably tons of partial file copiers available. These are the tools I used.
My Windows application calls a system command using _wpopen. This command produces a UTF8 response that I attempt to read using fgetws into a buffer of wchar_t. The problem is that the result in my buffer is not correct. There might be a problem with character widths as my buffer contains 12 characters where in UTF8 it should contain only 4. I use Microsoft Visual Studio 2010.
I have independently verified that the system command produces proper output. Thus, it is somehow the reading operation that messes up the encoding. What to do? Thank you!
The fgetws function expects the input to be either MBCS or UTF-16 depending on whether you open the file in text or binary mode. It does not process UTF-8.
Instead, use fgets and then explicitly convert from UTF-8 to whatever encoding you're wanting to use.
I would like to know what is the maximum length of a String when saving in the classic preferences System:
var prefs = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
prefs.setCharPref("com.exemple.namespace.preference", potentiallyLongString);
Couldn't find it in official documentation.
Note: I tried to type in more than 255, it works on Firefox 3.6, but I'm looking for a documented answer which would certify that length L works since version V.
Since there was no documentation, I just though of trying it anyway (at the most it'd have crashed my browser). I tried to the extent of 1,51,276 characters - and it worked perfectly fine. Trust me, I even matched the characters to test the reliability. :) Of course, doesn't mean you should use it regularly to those extents. ;). Just to give you an idea, that'd be around 30,000 words of English language, and has more number of characters than the whole script of the Movie Matrix (part 1).
I didn't try for more, as Notepad++ had started becoming slow in copying and pasting those many characters.
(Test Environment: Firefox 24, Windows 7 64 bit)
Edit: While I was trying this, I also noticed that even though it works for enormously large values, after some 4000 characters, Firefox starts giving a performance warning in the Error Console. So take what you want to from this.
There's no documentation on that. You shouldn't store unreasonably large strings in prefs -- if you're not sure if it will be reasonable, it's likely not a pref.
This is a real shot in the dark, however maybe someone had a similar issue. Some console apps are being invoked by either SQL Server 2008, or Autosys (job schedule) under Windows Server 2008; output results of execution are being saved into .txt files. Every so often, with no definite pattern as far as I can tell saved output is displayed as a series of what I presume are Chinese characters. Have anyone encountered phenomenon above?
Typically when you discover chinese characters in output unexpectedly, it's because someone passed a 7-bit or 8-bit character array to an API which expected an array of unicode characters. The system interprets the 8-bit characters as 16 bit unicode characters and they end up being interpreted as unicode characters. At some point later the unicode characters are converted back to 8-bit characters, probably just before they're saved to the text file.
Note: This is an oversimplification but it should be enough to help you figure it out.