Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Building & using U++ without TheIDE
Re: Building & using U++ without TheIDE [message #11569 is a reply to message #11562] Mon, 17 September 2007 22:28 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Mon, 17 September 2007 12:33


redistributing a release-only lib to reduce final EXE size.



I would rather follow this approach.

Or perhaps even better, you can make debug version - with runtime checks but without the debug info.

BTW, as I think you know, you can run TheIDE in commandline mode too, so automated generation tool does not rule out use TheIDE as build tool. I am even willing to add functions to generate .libs directly - but I do not really know how to group all the stuff to libs.

Mirek

P.S.: Looking at all troubles you have with this reminds me why we have created theide Smile For the first 2 years, U++, named SQL++ back then, was developed with Visual Studio 6.0...
Re: Building & using U++ without TheIDE [message #11571 is a reply to message #11569] Mon, 17 September 2007 23:47 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
luzr wrote on Mon, 17 September 2007 22:28

sergei wrote on Mon, 17 September 2007 12:33


redistributing a release-only lib to reduce final EXE size.



I would rather follow this approach.

Or perhaps even better, you can make debug version - with runtime checks but without the debug info.

BTW, as I think you know, you can run TheIDE in commandline mode too, so automated generation tool does not rule out use TheIDE as build tool. I am even willing to add functions to generate .libs directly - but I do not really know how to group all the stuff to libs.

Mirek

P.S.: Looking at all troubles you have with this reminds me why we have created theide Smile For the first 2 years, U++, named SQL++ back then, was developed with Visual Studio 6.0...




Well, I want to keep SCU approach for debug. Debug EXEs are about 13MB - not too much. The heavy point in favor of this system is being able to step in U++ source during debug. + You could also easily modify U++ source while developing/debugging. So IMHO debug lib isn't necessary.

Release lib is also not necessary. It would be just an improvement for EXE size (I could create a lib with SCU approach, but it wouldn't make any difference - including a package would link all of it).

The problem with precompiled header vs SCU is the need to create project files. With SCU you can redistribute the source, user just includes necessary packages. With precompiled header you have to setup project files with all cpps + precompiled header to build a lib. Which isn't trivial, since not all cpps actually should be compiled. So, SCU gets a point for maintainability. Precompiled header is worth it only in release - smaller EXE. And only for programs that don't utilize most of the code in packages they use.

More interesting solution could be splitting packages, like instead of one huge CtrlLib, several with different kinds of widgets. But that's probably just too much work...


P.S. devpacks are released every 2-3 weeks, right? Can I get the current source tree somewhere?
Re: Building & using U++ without TheIDE [message #11572 is a reply to message #11571] Tue, 18 September 2007 00:08 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Mon, 17 September 2007 17:47


P.S. devpacks are released every 2-3 weeks, right?



In theory, they should be released each week Smile
Re: Building & using U++ without TheIDE [message #11573 is a reply to message #11548] Tue, 18 September 2007 00:32 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
sergei wrote on Mon, 17 September 2007 11:07



Animated Hello example (full rebuild):
Code::Blocks svn4421 / MinGW 3.4.5 (Debug) : 1:18 / 241 warnings / 11.7MB.
Code::Blocks svn4421 / MinGW 3.4.5 (Release): 2:59 / 252 warnings / 3.3MB.
TheIDE 708dev2b / MinGW 3.4.2 (Debug): 1:11 / 0 warnings / 13.2MB.
TheIDE 708dev2b / MinGW 3.4.2 (Optimal): 2:39 / 1 warning / 1.6MB.




Update:
I've somewhat refixed zlib, so now no compile errors on MSVC rebuild.
Same Animated Hello full rebuild:
MSVC 8.0 (Debug) : 0:23 / 73 warnings / 3.9MB
MSVC 8.0 (Release) : MS Linker crashed. First time this happened to me Laughing
--> fatal error LNK1000: Internal error during IMAGE::BuildImage

Google found this: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedb ack.aspx?FeedbackID=100217
Should install SP1...
Re: Building & using U++ without TheIDE [message #11574 is a reply to message #11493] Tue, 18 September 2007 02:35 Go to previous messageGo to next message
tvanriper is currently offline  tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
Member
Quote:


sergei wrote on Sat, 15 September 2007 15:22

Have you tried using MS Unicode Layer for Win9x? I never did, but from the description it doesn't look much complicated. That way all builds could be Unicode.

luzr wrote on Sat, 15 September 2007 16:00

Well, but that is not out-of-box solution...



I have had quite a bit of experience with using UNICOWS, and can at least comment on its use, and perhaps offer an alternative idea.

It is, and it isn't an out-of-box solution. To use it, you have to link to a .lib file provided by Microsoft in a special way (it has to be the first library linked, then subsequent libraries can link... otherwise the system won't work). And you have to distribute a 'unicows.dll' (if I remember the name properly) with the application on Win9x-derived OSes (but you don't have to distribute it on non-Win9x-derived OSes). Otherwise, the application will call the Unicode versions of the Win32 API calls, and Mysteriously Bad Things Will Happen.

So, yeah, you could distribute applications with it 'out-of-the-box' in many cases, but for Win9x, you'd have to drop in that DLL. And... well I don't know Microsoft's position on the distribution of this library (or the .lib file, for that matter). I wouldn't think they'd have a problem, but who really knows? At the very least, it's kind of painful to set up.

All of this said, they aren't really doing anything that's terribly mysterious. I haven't looked over all the Win32 API calls you're making, but chances are you could probably do something like unicows.dll yourself by reproducing the wide versions of the function calls yourself, having them call the ANSI versions on 9x systems (doing the Unicode-to-ANSI conversions between the wide/narrow API calls), or pass-through to the Unicode versions on other systems.

Depending on the volume of code involved, this might not be so bad. Or, it could be a nightmare. I don't know... I haven't looked too deeply into Ultimate++'s inner-workings to see how much of the Win32 API you're using.
Re: Building & using U++ without TheIDE [message #11577 is a reply to message #11360] Tue, 18 September 2007 03:04 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Update: I've found a flaw in my SCU method. Since main.cpp will contain all U++ code due to the includes, any change in main.cpp will require full rebuild - not nice. I've reworked the structure - now there are 2 additional files - UppBase.h and UppBase.cpp. To use U++, user should copy & add both to his project. UppBase.h may be included in all source files that use U++. Also, UppBase.h contains #includes of packages that should be used. UppBase.cpp is a helper source, that will be the SCU. Unless it's changed (and it will change only if UppBase.h changes - which probably happens only when packages set changes), full rebuild of U++ won't be necessary.

Surprisingly, this method allowed me to detect more bugs. That's because all U++ headers are included before the first U++ cpp. Example: IsClipboardFormatAvailable is used in Draw/MetaFile, and it is defined in CtrlCore/CtrlCore.h. Seems fine, usually is fine, but actually incorrect. Draw package doesn't declare in uses (Draw.upp) that it uses CtrlCore, yet it uses its function. Not sure what's the best solution (easiest is to add CtrlCore to Draw's uses).

P.S. .upp inconsistencies that still haven't been corrected (as of 709dev1):
ide/VectorDes uses VectorDes (itself?, and wrong folder)
Ole/Ctrl/Calc and some Geom packages use T??? packages (such don't exist)
coff/uar/uld/uar.upp - probably should delete whole folder...

Re: Building & using U++ without TheIDE [message #11582 is a reply to message #11572] Tue, 18 September 2007 08:30 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

Quote:

In theory, they should be released each week

But please forgive maintainers to do it less often sometimes. Life is life.. Wink
Re: Building & using U++ without TheIDE [message #11590 is a reply to message #11360] Tue, 18 September 2007 18:05 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
OK, the issue with clipboard had nothing to do with dependencies, it was an API call mistaken for U++ function by the compiler. :: solved it.


I've updates to SP1, yet the error didn't go away. At least now it's preceded with C1001 - internal error of compiler. Again, release-only problem, debug works. Compiler's error is on line 54 of RichText/txtop.cpp. Which is: if(update). Yeah, that's one complicated line Razz
Any help would be welcome.

That's what I got:
d:\programming\upp\richtext\txtop.cpp(54) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'F:\SP\vctools\compiler\utc\src\P2\main.c[0x10BF5F00:0x00000 02C]', line 182)
To work around this problem, try simplifying or changing the program near the locations listed above.

For the record, F: is a CD drive Razz


Currently I'm rather pleased with the results (MS bug isn't my fault...). I'll test some more example projects (see how .iml and .lay work, test zlib), and retry unicode filenames. Then I'll upload everything.

For now, I'm attaching Animated Hello project. It won't compile without packages headers I've generated, but I'd like to know what you think about the way a typical U++ project on CodeBlocks/MSVC would look (I mean the sources).


P.S. I decided to try out ld and ar replacements.

Animated Hello full rebuild (debug + release):
MinGW 3.4.5 (original) : 4:27 / 562 warnings / 11.9MB + 3.3MB
MinGW 3.4.5 (U++ ld and ar) : 4:14 / 562 warnings / 11.1MB + 3.2MB

-> 5% reduction in build time, 7% reduction in debug EXE size, 1% reduction in release EXE size. Are these the common results? And is it safe to use these programs (I'm somewhat uncomfortable with patching the compiler).
  • Attachment: UppTest.zip
    (Size: 4.69KB, Downloaded 296 times)
Re: Building & using U++ without TheIDE [message #11591 is a reply to message #11590] Tue, 18 September 2007 19:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Tue, 18 September 2007 12:05

OK, the issue with clipboard had nothing to do with dependencies, it was an API call mistaken for U++ function by the compiler. :: solved it.


I've updates to SP1, yet the error didn't go away. At least now it's preceded with C1001 - internal error of compiler. Again, release-only problem, debug works. Compiler's error is on line 54 of RichText/txtop.cpp. Which is: if(update). Yeah, that's one complicated line Razz
Any help would be welcome.

That's what I got:
d:\programming\upp\richtext\txtop.cpp(54) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'F:\SP\vctools\compiler\utc\src\P2\main.c[0x10BF5F00:0x00000 02C]', line 182)
To work around this problem, try simplifying or changing the program near the locations listed above.

For the record, F: is a CD drive Razz



Hehe, that one is well known here:) The same result with MSC7.1 and MSC8.

For regular work with theide, it is non-issue as for release mode BLITZ is not recommended anyway as it produces longer .exes.

Quote:


P.S. I decided to try out ld and ar replacements.

Animated Hello full rebuild (debug + release):
MinGW 3.4.5 (original) : 4:27 / 562 warnings / 11.9MB + 3.3MB
MinGW 3.4.5 (U++ ld and ar) : 4:14 / 562 warnings / 11.1MB + 3.2MB

-> 5% reduction in build time, 7% reduction in debug EXE size, 1% reduction in release EXE size. Are these the common results?



Well, perhaps for rebuilding everything, reduction in build time is not that significant. But if you are rebuilding just single file while developing, which usually takes about 2-3s, that 13s difference is quite welcome.

Quote:


And is it safe to use these programs (I'm somewhat uncomfortable with patching the compiler).



These really are not patches. These replacements are rewrites from the scratch, using U++ Core (NTL). That is where the speed comes from Wink

As for bugs, who knows... But originals are not completely bug-free either.

Mirek
Re: Building & using U++ without TheIDE [message #11604 is a reply to message #11360] Wed, 19 September 2007 00:43 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Update:

I'm done implementing unicode. I don't exactly like the way I did it, but it works. I prefer some global strings manager like the TSTR I suggested, but since Mirek said he doesn't want TCHARs I've updated all API calls manually. I added PLATFORM_UNICODE define, and replaced many #ifdef PLATFORM_WINCE with it. Conversion mostly implemented through ToSystemCharset and FromSystemCharset.

In the process I've also found and eliminated a "security vulnerability" (that's what memory bugs are called nowadays Razz ) in Log.h:

sprintf(h, "* %s %02d.%02d.%04d %02d:%02d:%02d, user: %s\n",
(const char*)FromSystemCharset(exe),
t.day, t.month, t.year, t.hour, t.minute, t.second, (const char*)FromSystemCharset(user));

I added the (const char*), otherwise I got segmentation fault in debug. Probably without the explicit cast sprintf thought that String is a char array.

I received another segmentation fault earlier (but maybe it was this one...), and that one was solved by replacing all To/FromSysChrSet with To/FromSystemCharset. Not a big deal IMHO, they were all used in Win32-specific code anyway...

I've tested unicode filenames - it did open a multilingually-named file and read its content successfully. I've also tested registry - successfully wrote that filename to a REG_SZ key, it's fine. Didn't try to create unicode-named keys (don't wanna kill my windows).

Next (final) step - zlib/lay/iml/images testing. If that goes well, I'll upload everything.


P.S. I'm working from Code::Blocks when editing U++ source, rebuild for console project is half a minute. So I don't want a static lib for debug Smile Though GDB / Code completion don't work that well - GDB reports most stuff in U++ source as incomplete type (so I have to Cout whatever I want to see), and Code completion usually can't find definition of things (but it does know function prototypes).

P.S.2 since you know about the MSVC bug, did anyone report to MS? There might be a chance that they fix it...


Edit: I think UTFBOM class I posted above, or something else implementing that functionality, should be added to some place in U++. That way unicode support will be complete - unicode filenames + unicode text.

[Updated on: Wed, 19 September 2007 01:07]

Report message to a moderator

Re: Building & using U++ without TheIDE [message #11605 is a reply to message #11604] Wed, 19 September 2007 09:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Tue, 18 September 2007 18:43

Update:

I'm done implementing unicode. I don't exactly like the way I did it, but it works. I prefer some global strings manager like the TSTR I suggested, but since Mirek said he doesn't want TCHARs I've updated all API calls manually. I added PLATFORM_UNICODE define, and replaced many #ifdef PLATFORM_WINCE with it. Conversion mostly implemented through ToSystemCharset and FromSystemCharset.

In the process I've also found and eliminated a "security vulnerability" (that's what memory bugs are called nowadays Razz ) in Log.h:

sprintf(h, "* %s %02d.%02d.%04d %02d:%02d:%02d, user: %s\n",
(const char*)FromSystemCharset(exe),
t.day, t.month, t.year, t.hour, t.minute, t.second, (const char*)FromSystemCharset(user));

I added the (const char*), otherwise I got segmentation fault in debug. Probably without the explicit cast sprintf thought that String is a char array.

I received another segmentation fault earlier (but maybe it was this one...), and that one was solved by replacing all To/FromSysChrSet with To/FromSystemCharset. Not a big deal IMHO, they were all used in Win32-specific code anyway...




Uh oh, that is no good. There definitely should be FromSysCharset, which returns a pointer to static char * array.

The reason is that Log is supposed to work independently from the rest of U++, so that it can be used in situation when the rest failed or is not available. By using vanilla FromSystemCharset, you make it dependent on String and in turn on memory allocator. Therefor it will not work when heap crashes or cannot be used to debug memory allocator... Smile


Quote:


I've tested unicode filenames - it did open a multilingually-named file and read its content successfully. I've also tested registry - successfully wrote that filename to a REG_SZ key, it's fine. Didn't try to create unicode-named keys (don't wanna kill my windows).



Sort of redundant work. The final solution will use dynamic .dll loading to choose between W and A variants.

Quote:


P.S.2 since you know about the MSVC bug, did anyone report to MS? There might be a chance that they fix it...



No.

Quote:


Edit: I think UTFBOM class I posted above, or something else implementing that functionality, should be added to some place in U++. That way unicode support will be complete - unicode filenames + unicode text.



Well, the question is the definition. Thinking about it, I just fail to see what is the exact description. If detection of utf-8 files is the purpose, that can be easily done withou specific code. Also, what is going to happen if there is no UTFBOM?

Should it be available as

bool SkipUTFBOM(Stream& in);
const char *SkipUTFBOM(const char *s);

?

Mirek
Re: Building & using U++ without TheIDE [message #11607 is a reply to message #11605] Wed, 19 September 2007 10:12 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
I see now... I knew there should've been a good reason for a second set of charset functions. OK, I'll reverse the changes and see if that works.

About registry:

bool SetWinRegString(const String& string, const char *value, const char *path, HKEY base_key) {
HKEY key = 0;
if(RegCreateKeyEx(base_key, ToSystemCharset(path), 0, NULL, REG_OPTION_NON_VOLATILE,
KEY_ALL_ACCESS, NULL, &key, NULL) != ERROR_SUCCESS)
return false;
#ifdef PLATFORM_UNICODE
WString wstring = string.ToWString(); wstring.Cat(0, 1);
bool ok = (RegSetValueEx(key, ToSystemCharset(value), 0, REG_SZ, (const byte*)(const wchar*)wstring, (wstring.GetLength() + 1)*2) == ERROR_SUCCESS);
#else
bool ok = (RegSetValueEx(key, value, 0, REG_SZ, (const byte*)(const char*)string, string.GetLength() + 1) == ERROR_SUCCESS);
#endif
RegCloseKey(key);
return ok;
}


The #else part is what was prevoiusly the code (I added the casts, though). Linking that to W version wouldn't be possible - defining UNICODE without #ifdef would cause an error of cast of char* to WCHAR*.

I found that I didn't modify everything, since console apps don't include much Razz Then I found that already exists a macro L_(). Thus using TCHAR instead of char/wchar, + L_() and To/FromSystemCharset might indeed remove these #ifdefs. But that would be later, first to ensure everything works.

I'm not sure how you want to use dynamic dll loading. Change all #ifdefs into if/elses, and explicitely call W and A versions, to enable runtime switching between ANSI/Unicode?



UTFBOM: Skip BOM of UTF-8 / UTF-16 LE / UTF-16 BE files (not only UTF-8), and read ASCII/UTF-8 (if there's no BOM, it's considered ASCII) into String, UTF-16 LE/BE into WString. Convert UTF-8 String into UTF-8 / UTF-16 LE/BE with/without BOM. I guess it should be:

int FromFileCharset(const String& s, String* os, WString* ows);
String ToFileCharset(const String& s, int bytes, bool BOM = true, bool LE = true);
String ToFileCharset(const WString& s, int bytes, bool BOM = true, bool LE = true);

(maybe should add ASCII -> UTF-8 conversion if there's no BOM, since chars > 127 could cause invalid UTF-8, being just system-charset chars)



Re: Building & using U++ without TheIDE [message #11609 is a reply to message #11607] Wed, 19 September 2007 10:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Wed, 19 September 2007 04:12


I'm not sure how you want to use dynamic dll loading. Change all #ifdefs into if/elses, and explicitely call W and A versions, to enable runtime switching between ANSI/Unicode?



Yes. With .dli, it is not as much trouble as it seems. In fact, you forced me to work on it right now Wink

Quote:


UTFBOM: Skip BOM of UTF-8 / UTF-16 LE / UTF-16 BE files (not only UTF-8), and read ASCII/UTF-8 (if there's no BOM, it's considered ASCII) into String, UTF-16 LE/BE into WString. Convert UTF-8 String into UTF-8 / UTF-16 LE/BE with/without BOM. I guess it should be:

int FromFileCharset(const String& s, String* os, WString* ows);
String ToFileCharset(const String& s, int bytes, bool BOM = true, bool LE = true);
String ToFileCharset(const WString& s, int bytes, bool BOM = true, bool LE = true);

(maybe should add ASCII -> UTF-8 conversion if there's no BOM, since chars > 127 could cause invalid UTF-8, being just system-charset chars)



I see. In fact you suggest something like LoadUnicodeAny, which detects the kind of file and loads UTF-8 or UTF-16LE or UTF-16BE.
Returning WString (it is easy to convert it to String).

Hm, perhaps there should be two variants after all to avoid unnecessarry UTF-8 -> UTF-16 -> UTF-8 conversion...

Mirek
Re: Building & using U++ without TheIDE [message #11611 is a reply to message #11609] Wed, 19 September 2007 11:18 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Why need dli? You already have all functions from #include <windows.h>. The trouble would only be explicitly calling A and W version. Thinking of it, it sounds nice - make PLATFORM_UNICODE a global boolean, initialized to true, unless OS is Win9x. But I'd prefer to finish the way I started to see everything work.

UTF-8 -> UTF-16 -> UTF-8 won't happen. FromFileCharset returns String if it's ASCII/UTF-8 and WString if it's UTF-16. It returns amount of bytes. 0 -> ASCII / String, 1 -> UTF-8 / String, 2-> UTF-16 / WString (4 -> UTF-32 / WString, but not implemented). What could happen is UTF-16 -> WString -> String, but UTF16 -> WString isn't expensive.


I wanted to compile UWord (now in ANSI, GUI Unicode isn't complete yet) to see if zlib work (UWord.iml), and found an interesting problem in PdfDraw:

ScreenDraw sd;

That causes a warning of statement is a reference not a function call. + error about sd definition. In Draw/DrawWin32, ScreenDraw is a class, but also:

ScreenDraw& ScreenDraw()
{
return Single<ScreenInfoClass>();
}

That's a singleton? Whatever it is, it doesn't work - ScreenDraw sd; is recognized as a function name, not class type. Any suggestions how to fix?


P.S. Why does U++ use so many global functions? I prefer .Net-style - tree-like organization using namespaces/classes. After all, gathering functions into static classes should be realtively easy, and at the cost of some extra typing you (potentially) resolve naming conflicts, and make stuff easier to find. E.g. I may not know that there's a function named GetWinRegString hidden somewhere in Core/Win32Com. But if there was a class Registry, it would be more likely that I'd find it by typing Registry::. Plus that would be an OOP approach Very Happy
Re: Building & using U++ without TheIDE [message #11612 is a reply to message #11611] Wed, 19 September 2007 11:33 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
... It was way too tempting to see if UWord works, so I removed PDF and built without. 5:36, full debug+release rebuild (without PDF). 12.1MB debug, 4.2MB release. It works, and most importantly, I see the icons on toolbar, these look just fine. It means new zlib works, right?
Re: Building & using U++ without TheIDE [message #11613 is a reply to message #11611] Wed, 19 September 2007 11:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Wed, 19 September 2007 05:18

Why need dli? You already have all functions from #include <windows.h>.



Yes, but it would not start on Win98 ("missing dll call").

Quote:


UTF-8 -> UTF-16 -> UTF-8 won't happen. FromFileCharset returns String if it's ASCII/UTF-8 and WString if it's UTF-16.



How? Sure, you can make it return something more complex, but I would prefer two functions: one returning String and other WString.

Quote:


I wanted to compile UWord (now in ANSI, GUI Unicode isn't complete yet) to see if zlib work (UWord.iml), and found an interesting problem in PdfDraw:

ScreenDraw sd;

That causes a warning of statement is a reference not a function call. + error about sd definition. In Draw/DrawWin32, ScreenDraw is a class, but also:

ScreenDraw& ScreenDraw()
{
return Single<ScreenInfoClass>();
}

That's a singleton? Whatever it is, it doesn't work - ScreenDraw sd; is recognized as a function name, not class type. Any suggestions how to fix?



Now this is really interesting. It is obvious bug (minor, this is just something forgotten), just tell why in theide it compiles without a error, in both MSC and all versions of mingw? Smile

Maybe different way of SCU? (Your SCU is bigger than mine? Smile

Quote:


P.S. Why does U++ use so many global functions? I prefer .Net-style - tree-like organization using namespaces/classes. After all, gathering functions into static classes should be realtively easy, and at the cost of some extra typing you (potentially) resolve naming conflicts, and make stuff easier to find.



Actually, if you look a bit more carefully, then either these are really very globally used names (e.g. AsString) - there is a limited number of such cases, or they are carefully bound to parameters so that C++ overloading resolves the conflicts.

Believe or not, function name conflicts are not an issue. (Moreover, everything is still in U++ namespace).

Quote:


Plus that would be an OOP approach Very Happy



I like multi-paradigm approaches more Smile

Mirek
Re: Building & using U++ without TheIDE [message #11614 is a reply to message #11611] Wed, 19 September 2007 11:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Wed, 19 September 2007 05:18



ScreenDraw& ScreenDraw()
{
return Single<ScreenInfoClass>();
}




Forgot to say: Just delete it..Smile

Mirek
Re: Building & using U++ without TheIDE [message #11617 is a reply to message #11613] Wed, 19 September 2007 12:22 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Regarding UTF - I understand that. I made it take 2 pointers - to String and WString. That was for optimal conversion. I'll split that, and add a function that returns encoding bytes according to BOM - so if user wants to go for the faster conversion, he would be able to choose between String and WString.

Regarding SCU - no idea... My SCU first includes all headers, then all sources (of packages used).

Tested PDF export, now works. Should complete unicode, and test layouts and more images.


P.S. tried Hebrew support in UWord. Pretty bad Sad While it does display correctly what I type, everything else doesn't work. E.g. no switch to RTL button, home/end keys work as in LTR, left/right work for some reason... Worse yet - it doesn't position the cursor where I see it:
(TEX|T)
If I type a letter I get:
(TELX|T)
Same goes for copy/paste of selected text, it doesn't select the correct text (selects same amount from other side).

Even worse in textboxes (like in save file). Not only inserting is wrong, but there's also a sliding problem - when you select text, it changes while you're selecting it (slides into selection from other side). I've seen that in a few apps before, makes editing text impossible.

Could at least partial support be improved? I mean, ignore keys and RTL layout. At least should be WYSIWYG in insert/delete/select/copy. BTW, export to PDF reversed Hebrew text. Expectable, but not nice.
Re: Building & using U++ without TheIDE [message #11618 is a reply to message #11617] Wed, 19 September 2007 12:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Wed, 19 September 2007 06:22


E.g. no switch to RTL button, home/end keys work as in LTR, left/right work for some reason... Worse yet - it doesn't position the cursor where I see it:
(TEX|T)
If I type a letter I get:
(TELX|T)
Same goes for copy/paste of selected text, it doesn't select the correct text (selects same amount from other side).

Even worse in textboxes (like in save file). Not only inserting is wrong, but there's also a sliding problem - when you select text, it changes while you're selecting it (slides into selection from other side). I've seen that in a few apps before, makes editing text impossible.

Could at least partial support be improved? I mean, ignore keys and RTL layout. At least should be WYSIWYG in insert/delete/select/copy. BTW, export to PDF reversed Hebrew text. Expectable, but not nice.



Hey, Sergei, I have told you that RTL is not implemented.

In fact, so far there was nobody capable about even commenting this issue. We could base it on some generic info available, but I guess this would not really help... We need a real person who knows how this is supposed to work;)

Mirek
Re: Building & using U++ without TheIDE [message #11621 is a reply to message #11360] Wed, 19 September 2007 14:22 Go to previous messageGo to previous message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Well, I just hoped that it might simply work... I could explain whatever you want to know but I doubt that I'll be able to code handling myself.

I'm trying to compile HomeBudget - GridCtrl/GridDisplay.h didn't have NAMESPACE_UPP. sqllite3 has stuff like this:
typedef struct sqlite3_stmt sqlite3_stmt;
That have to be commented out to work in C++. Now, do I have to install SQL or something to test this project? I don't know how SQL works...

More: GridCtrl contains stuff like this: LG("speedx %d, speedy %d", speedx, speedy). LG is: #define LG(x) s << x << '\n'. So I believe something is wrong about the syntax.


I'm not sure if I'll be able to make sqllite work with SCU, since it's 2MB of source. Actually, the biggest package of U++... Better finish unicode (testing UWord).



Previous Topic: *.tpp files in SVN
Next Topic: console + WIN-GDI
Goto Forum:
  


Current Time: Thu Mar 28 13:49:17 CET 2024

Total time taken to generate the page: 0.01880 seconds