|
No i don't think that's good
Compiler will comile evrything. Only a hacker will get extendet future.
You should use:
#define IsExtended
#ifdef IsExtended
ToDo:
#endif //IsExtended
In this way the compiler will comile the extendet future.
if you don't want to compile, then just delete "#define IsExtended"
What do you think
|
|
|
|
|
You're assuming he's using C++. There's a 1/3 chance of that, here.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I'm using c#  so the suggestion of sakida also works in c# right? i believe the syntax is also #ifdef correct?
|
|
|
|
|
I don't think #define works in C#, no. It's a holdover from C, in C++.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
found #define, #if & #endif in the MSDN (Filtered by C#). So I believe there is. Thanks for the help! 
|
|
|
|
|
As Sakida said, you don't want to compile the functionality you're not offering into your code base. So create two projects, so that only one has all the functionality, and the one with limited functionality needs to somehow figure out not to show the options that are missing from menus, etc. Something like what you suggest would work for that part.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I see... I'm thinking about separating them into two projects and have a
<br />
#define IsExtended<br />
<br />
#if IsExtended<br />
using extended;<br />
#endif<br />
What do you think? And how can I make the #define IsExtended line globally accessible by all forms?
By the way, is the syntax correct? ^^
Thanks,
~Rafferty
|
|
|
|
|
If the #define happens in code, then it's a waste of time. If you can't create a define as a build property ( as you can in C++ ), then the mechanism you use to change builds remains a manual one.
It seems that C# works the same a C here, I didn't know ( I hated macros in C ). You can set the defined values in your build settings, so you can set up builds for more than one version, and wrap entire classes in #ifdef statements. Personally, ( and I did this on a project in C++ years ago ), I think this gets too messy, too quickly. Your code gets hard to read, and flow is hard to establish with little #ifdef blocks everywhere. The approach I suggest would force you to move most of the differences into entire classes that are excluded, and a #define could be used just for the code that controls what menu options are provided, as appropriate. The less #ifdef blocks you can have, the better.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
ahh.. that sounds doable. Did you just look it up in the MSDN Library? What's the keyword so I can read it too. I also don't know about how to customize build settings yet.
~Rafferty
|
|
|
|
|
Rafferty Uy wrote:
Did you just look it up in the MSDN Library?
The overall approach ? No, it's just what I would do.
Rafferty Uy wrote:
I also don't know about how to customize build settings yet.
Fair enough. On the menu, go to Build/Configuration Manager. choose 'new' in the drop down. Call it 'Demo version' or something. Do that twice, copy one from release and one from debug, and name them accordingly. Now in both of these projects, right click on the project name in the solution explorer and choose properties. Click on 'configuration properties'. The first of the three options below it is selected, and the first item in the list of options is compiler settings. DEBUG is defined for the debug version, in both cases, add the name of the define you want to check in your code. Now these builds will have that define set. HOWEVER, I'd recommend creating a new project that imports most of the other one ( i.e. looks at the same files ) and excludes the files that contain the stuff you don't want to offer in your demo version. Then you only need to use the #ifdef stuff to check your define before adding those items to menus, etc. If you do it all in one project, then you'll need to #ifdef out entire files as well, which is just plain ugly IMO.
Either way, that's how you set up the defines in the build versions.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Wow that's great! I'll try to work on it
Thanks Mr. Christian. Maybe I'll just post again if I encounter any problem/difficulties
|
|
|
|
|
By all means, that's what we're here for
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi Christian,
How do you #ifdef out entire files? I may have to do this for some of the files. do I just do something like this?
#if ISEXTENDED<br />
#endif
Also, I tried what you suggested about moving the differences into a separate project. If the Main project has a reference to the Extended project, is it okay not to compile the extended project?
Thanks Much!
~Rafferty
|
|
|
|
|
Rafferty Uy wrote:
#if ISEXTENDED
// ... entire code here ...
#endif
That's it 
Rafferty Uy wrote:
Also, I tried what you suggested about moving the differences into a separate project. If the Main project has a reference to the Extended project, is it okay not to compile the extended project?
I wouldn't expect the projects to reference each other as a file, but to reference each others source files. Yes, you can build one and not the other if you want to.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Dear sirs:
I am developing a client application that retrieves files from an FTP site. I wish for these files to be secure. The methodology I have chosen to implement security is as follows: The files are initially encrypted on the server. A file is then downloaded to the user's machine and decrypted in an unobvious location, and then dislayed in the client application I have developed for viewing the files. When the user is finished viewing the document (closes it), then the file is re-encrypted.
The only drawback to this method is that while the files are opened by the client program (they are mostly adobe pdf files), the security of the files are compromised.
Does anyone have a better (and not too difficult) solution?
Thank you,
Rob Hyland
|
|
|
|
|
Once the files are on a local machine, where is the security issue ? If they are PDF's, they can't be edited by most people, do you want to display them without the user being able to give them to anyone else ?
I wonder if it's possible to decrypt the files in memory, and pass them to an IE control, which will render them for you ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi,
I've writen few small apps using doc/view architecture.
Now I want to port my apps using .NET framework,
is there any doc/view-like in.Net?
Thanks
|
|
|
|
|
Not specifically, but there's no reason why you can't emulate it. No matter which way you look at it, MFC does not exist in .NET, you'll be porting to a whole new windowing library, so it won't be the easiest thing in the world to do.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thanks for your information. But if I'd prefer using MFC rather than .NET, What about the future of MFC? Will it be obsolete like Win16 Apps when came Win32 Apps?
Is Microsoft still developing MFC? because I've heard that Microsoft stops developing VB6.
|
|
|
|
|
VB6 is as dead as the dodo, because it's evolved to VB.NET. MFC 6.0 is dead, because it's evolved into MFC 7.1. MFC didn't get a lot of attention in the last two compiler releases, but C++ certainly did. Either way, the framework exists, and you have the source code. I don't think MFC is the best way to go anymore, but people still write pre MFC style windows apps, you can use whatever framework you like.
If you're using MFC, why ask in the .NET framework forum ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Actually I plan to port to .NET framework,
but I don't want to waste too much time for porting my existing apps.
Maybe there's an existing MFC-like framework in .NET so I ask in this forum.
Thanx,
|
|
|
|
|
senzafine wrote:
Actually I plan to port to .NET framework,
Well, then use managed C++ to start with, and you'll be in the .NET framework. DON'T write an MFC app, .NET will not support it, you'll be creating rewrite headaches, unless you keep your presentation layer very seperate and resign yourself to rewriting it.
senzafine wrote:
Maybe there's an existing MFC-like framework in .NET so I ask in this forum.
There isn't one that's analogous to MFC, not that I know of.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi,
I have an app developed using Windows Forms. I need to save the size that the user resizes the app to, so as to open the app window to that size when the user restarts the app. I also need to save the desktop location of the app, so as to display the app window at that location when the app restarts.
What is the best way to do this?
I have implemented this using a config file, such that I save the size.width, size.height, and location.x, location.y of the app when the event to close the app is fired. The problem with this is that when the user closes the app in its minimized state, then the app size is 160 x 30, and the app re-opens at this size at the next restart.
Thanks.
-Shefali
|
|
|
|
|
Check first before writing to the config file ,if
if(this.WindowsState==FormWindowsState.Normal)<br />
{<br />
}
|
|
|
|
|
Hey guys, has anyone else run accross this behavior before?
When using dataadapter.update within the context of a transaction, if the transaction succeeds your datasource has .acceptchanges called and everything is fine. If that transaction fails however, .acceptchanges is still called.  
this just doesn't seem right to me? according to a post i found on google ms's recommended way of dealing with this is to make a copy of the data before submitting the update, then if the transaction fails, clear the data and merge the previous version back into the main dataset. i was baffled when i came upon this the other day.
does anyone have any insight as to whether this behavior might be changing in the next release of the bcl? i don't have any of the beta's to check it out and i'm more just curious than anything. seems like if the transaction failed they should just leave the rowstate data as is...
-jim
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
