|
Thankyou for the worship, contributions will be gratefully accepted. 
No, but seriously, implementing your own function queueing this way ios such a great solution to complex, event driven implementations that it ought to be taught in school. It has literally saved me many times. It is SO disjointed, so flexible.
One beauty is that a function, that expects a certain state, when run, and if that state is not there yet, can requeue itself, and because this is at low priority takes no CPU time. It is a beautiful engineering solution. You never get a deadlock situation. It can reduce any complex environment to simplicity. Seriously, I love it.
|
|
|
|
|
Munchies_Matt wrote: ios such a great solution
I didn't know you were an Apple Fanboi.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
FlagComposer: let's build a software tool using XML to define a set of national flags.
This project is mainly addressed to students or programmers who'd like to have a challenging programming task to solve as an exercise in their free time…
So, here is the description…
Let's imagine, we want a software tool to define a set of national flags. The tool should use XML data to (1) draw a GUI and (2) to generate an output.
Aim of this application is to build a GUI starting from a XML file (e.g., see "FlagComposer.xml" in the GitHub linked at the end of the post) and to generate an output XML file (e.g. "FlagGermany.xml") according to what has been set by the user in the GUI.
In input we have one (or more… but not simultaneously processable) XML file(s) defining which elements (graphical controls) should compose the GUI, which parameters are needed to define a flag, which values are valid; in output we want to have one XML file for each flag definition. It is not required to display an image of the flag: the XML file is all that we want to have as a result of the processing.
The application must read a XML file containing a "GUIDefinition" element and draw a graphical user interface accordingly. It must also be able to generate and write out a XML file containing a "FlagDefinition" element.
[Application is launched]
==>
[Read XML <guidefinition>]
==>
[Draw GUI accordingly]
==>
[Process user's "Save" or "Exit" command]
==>
["Save" creates XML <flagdefinition>]
==>
[Exit]
Starting from the <guidefinition> element of the input XML data, we want to build up a GUI where the user can enter the required parameters, for instance (…see "FlagComposer.xml"):
1. a "Name" should be entered through an editable text field;
2. a "Direction of Stripes" specification should be entered through a list box (or choice box) displaying the available options ("Horizontal" and "Vertical") and allowing the user to select one of them;
3. a "Number of Stripes" should be entered through a numeric spin box ranging from "MinValue" to "MaxValue" (eventually initialized to a "DefaultValue");
4. a set of list/choice boxes should allow the user to enter the colors of the flag: the GUI must provide N occurrences of the "Color of Stripe" parameter (list/choice boxes) according to the previously set "Number of Stripes".
Once the user has entered all the required data, an enabled button or menu option should allow him to generate and save the output XML file with the final <flagdefinition> element (to have an example of the output file, see "FlagGermany.xml").
To develop the application, free or open source tools should be preferred over commercial ones, but the choice of the programming language, IDE and framework, with which to implement the application, is ultimately left open to any option and demanded to the programmer (that is, to anyone who's going to try to implement a solution to this problem): you may choose whatever language or framework you like. Of course, the simpler and faster-to-implement-and-maintain the solution is, the more it will turn out valuable.
A set of XML files, to use as a model of the input data (<guidefinition>) that should be used by the application and of the output (<flagdefinition>) that should be produced, is available on GitHub (there you'll find XML data files only; there's no source code, as the application doesn't exist yet…):
https://github.com/FromTimeToTime/FlagComposer/
Please, fork the GitHub project to suggest your ideas or your implementation of a solution…
As you can see, the application that I'm asking you to design (and eventually develop) is just a "toy", but it could give me the crucial hint necessary to deliver a solution in the professional field where I'm working… and - yes - to save my job!
(In the company where I'm currently employed I'm struggling to solve a problem with several technical analogies already since a long time, unfortunately without success till now… Well, I'm just a junior developer, after all; I hope you'll understand…)
XML is a ground requirement in this "FlagComposer" simply because it is a requirement (for the communication between many software components, having distinct producers even) in the project I'm professionally working on. For understandable reasons, I couldn't post anything related to the real project… but in the "FlagComposer" problem (note again that there's no such application yet!) a few technical aspects of the "real" project, whereto I have to deliver a solution, are reflected.
Also links to useful resources and to existing source code doing more or less what is involved here could be very helpful!
Any contribution will be very appreciated! Thanks a lot in advance!!!
|
|
|
|
|
So what's the question?
You read some xml, and use it to create a flag; consisting of "shapes" and "colors".
But you haven't accounted for some of the more "graphic" flags.
Holland and France flags are easy; not so much coming up with a "snake" or an "eagle" (Mexico).
You now have to define (graphics) "paths"; or you're back to using images.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
The application that I'm asking you to design (and eventually develop) is just a "toy", intended to explore the possible solutions to a problem with the described technical requirements (in short: XML input to generate a GUI; XML output to return an answer to the user): I'm not aiming at representing faithfully all the graphical characteristics of the flags of the countries of the world; painting the flag graphically is not required and doesn't interest me at all, indeed. Unfortunately, I couldn't think of a better sample project to explore the issues that I'm facing with the industrial software I'm currently dealing with…
|
|
|
|
|
yobibytes wrote: The application that I'm asking you to design (and eventually develop)
Sorry, but this site does not provide code to order. If you want this tool then you need to do the work to create it.
|
|
|
|
|
yobibytes wrote: The application that I'm asking you to design (and eventually develop) is just a "toy"
So, you said in your original message that you want us to do this to save your job. Unfortunately, that's not the way we work here - if you want code to order, try RentACoder (or whatever it's called nowadays). You have to understand that we are all volunteers and the vast majority of us code professionally, so we don't have the time or inclination to write this for you.
It sounds as though you're trying to create a "XAML" style of application - search for Marc Clifton's excellent MyXaml series of articles. These should help you.
This space for rent
|
|
|
|
|
Thanks a lot for the tip, Pete! Tips that puts me hopefully on the right path are exactly what I'm looking for… Unfortunately, Clifton's www.myxaml.com website is not reachable… maybe the MyXaml development technology is something obsolete?
|
|
|
|
|
He's a CodeProject MVP[^]. He posted MyXaml as a series of articles here.
This space for rent
|
|
|
|
|
Also take a look at his MycroXaml project in his articles list. It's a smaller, lighter weight solution to the problem.
This space for rent
|
|
|
|
|
|
Why didn't you say that's what was needed (an xml editor); instead of going on about "flags":
XML Notepad - Home
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I'm planning to develop a Winsock Layered Service Provider. Given that the provider DLL will end up being loaded into system processes as well as user ones, are there any restrictions on the uses of the C++ runtime and/or MFC inside these processes?
Am I going to have to develop it in straight C? (I hope not.)
When I say system processes, I mean user mode system processes. The LSP is not a kernel mode component.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Its a user mode process, system or app, then yes, any MFC code can be used.
Oh, and you can write C++ in the kernel, it does after all just end up as assembler, same as C. The issue with MFC are the libraries it uses. These just arent kernel usable.
|
|
|
|
|
I personally wouldn't recommend using MFC for anything that doesn't involve a GUI. It's relatively large and really buys you minimal help for most things (although it does help a lot with GUI objects).
As to building an LSP (note the "deprecated" part)...
Layered Service Provider - Wikipedia[^]
As to building this type of DLL using C++, sure, you probably just need to export some functions using the 'C' style exports so they could be loaded. It's common practice so you'll find examples everywhere.
|
|
|
|
|
Albert Holguin wrote: As to building an LSP (note the "deprecated" part)...
I know it's deprecated, but I don't have the resources or the time to learn how to write a kernel mode filter driver for the new Windows Filtering Platform.
Plus I don't think it will be removed because LSPs are part of the Winsock spec.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I'm currently in the process of investigating how to best implement a common login system for all our applications. The logins can have different types of users: some are system users or even crowd sourcing members, others are used for determining user settings for an application and others are subscribed to newsletters or alerts of some type.
The idea is to have one common database of users or contact information which all applications can use, similar to an SSO system.
apart from the usual advice: password rules, encryption methods (using salts), SQL injection, using secure transport etc... I don't find that many tools that allow this (preferably for free, like an open source thing) and honestly, perhaps I'm overly suspicious, one is never sure they tackle security right and whether they are flexible enough to handle 100% of the requirements. And finally if they are easy in maintenance and usage (installing, configuring or compiling, ...) ?
Secondly you have the openid, oauth, ... systems that allow social media login. Looks nice, but I have the feeling that you never get all the information you want and this is also on provider's goodwill (IOW they can stop the service at any time, not that they will, but they could?) and the technology could change, forcing you to evolve on a regular basis. Lastly, though I'm not 100% sure, I seem to remember reading somewhere that more institutes/companies are stepping away from openid (I think in favor of another technology). Can't remember the source.
question 1: Any recommendations on a system? Free or paying.
question 2: Why would or wouldn't I adopt a social media SSO?
question 3: apart from the logical things to watch out for: any additional advice?
Many Thanks. 
|
|
|
|
|
So are you guys not already using a domain with an associated LDAP mechanism? That's really the best way that I know of to handle Identity Management in a distributed and diverse system.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
This system goes wider than the domain. Some stranger can register and subscribe for any of the services we provide. I'm guessing yahoo, twitter, facebook, ... don't use ldap to register their user, right?
|
|
|
|
|
Well that's the crux of the issue. You could introduce a guest OU that has groups and user slots for the psudo-anonymous users off the network, but generally that's more overhead than should really be required.
The reason that I mention this is that you said you're looking for a single login mechanism, but handling LOB accounts and unverified accounts should be inherently different (an unverified account should never be granted admin access, but if you use a semi-trusted authentication system how do you handle fully trusted authorization?).
So there's a few approaches. One is to add all users to the domain as mentioned and use a Guest container. Another is to use a mechanism like OAuth2 (and provide an OAuth provider from the domain for LOB accounts) and move administration to a separate application that is only available to domain accounts. That doesn't meet your single AAA criteria, though. Or you could setup an authoritative database, but that would place your LOB accounts at the exact same security context as your unverified accounts without a bunch of code overhead, which is not something I could suggest.
Ultimately I'd say that the requirements need to be reviewed. I'd personally suggest using domain authentication for applications that provide administrative access, and using OAuth2 for public endpoints, but I'm not familiar with your system and overall requirements. This has the benefit of having a single authentication mechanism per application purpose, without co-locating AAA information.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Thanks for the answer.
It's not an easy task (we have lot's and lot's of history which resulted in a mess I'm now trying to clean up, ... a little) and the requirements will be more definitive when I talk to the necessary people concerning budgets and timing. I'm just gathering information for now on what's possible and what would be the best approach in which situation. Your answer is definitely helpful in that regard. 
|
|
|
|
|
Best of luck. The real problem you're going to face is to convince management to get behind a system that's designed to be security-minded from the ground floor. Fortunately(ish) 2016 was a hack-heavy year, so you'll likely get less push-back about "intangibles". Silver linings.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Hello,
there is the saying "one picture describes more than thousand words".
I also find myself in a situation, where an image inside the source code would describe the situation so much faster and easier, than text. Especially for non-technical domain code.
Therefore, I think enabling images inside source code would be a really awesome, helpfull extension. But as a matter of fact, this feature does not exitst. Am I maybe missing something here? What's your opinion on that topic?
regards
|
|
|
|
|
My opinion? It's stupid.
What would this picture describe in the code? Absolutely nothing.
Not to mention how you could be possible even "type" that code nor how it would even be saved.
The closest you can get to any kind of usable concept that resembles something like this would be an image in the project resources.
|
|
|
|
|
D4rkTrick wrote: What's your opinion on that topic?
There should not be any pictures, animated gifs, advertising-banners or flash in the source-code. It is plain text, editable in any text-editor.
I agree that a picture may explain a lot more and better, but source-code is not the documentation. See this[^] thread.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
