|
Sounds like they were able to shake it off.
|
|
|
|
|
I have been working on building GDBM with MSVC, and I ended up creating a VS project for that, and after some fiddling, I got it to work.
It took about 30 minutes to get it working, and no patches were needed.
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???
|
|
|
|
|
GDBM == Gosh Darn Big Mofo?
|
|
|
|
|
Gnu DBM. It is an extended implementation of the UNIX DBM interface.
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???
|
|
|
|
|
I remember writing such a file manager (I can't see why they call it DB?!) for my final project at the collage to help me with the data part...
I didn't want to use COBOL (which has it built in) and connecting the mainframe for SQL was out-of-question, so I wrote a file manager to store indexed data...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Brisingr Aerowing wrote: It took about 30 minutes to get it working, and no patches were needed.
It's nice when a project works out easier then expected.
|
|
|
|
|
Did anyone try using it? Opinions or ideas?
Xaml still seems to be ok so why would one switch to WinJS?
I can find some comparison charts on the internet but nothing beats experience.
|
|
|
|
|
WinForms is still ok, so why would anyone switch to Xaml?
Yes, serious question; the editors from the older versions of VS (2012, 2013) are kinda crap. Read a post here today that they are still crap in 2015.
Why would anyone want to use a techbnology that still feels like it is in beta? The comparison chart will tell you that WPF is hardware-driven, where WinForms is drawn by the CPU. Given the fact that WinForms is created for a very outdated and very slow CPU, I do not see this as a serious advantage that outweighs the added complexity nor the vendor-lockin on the platform.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I know what you mean - I looked at moving from WinForms to WPF a couple of years ago, but it looked and felt very "unfinished", a work in progress as it were. And the VS support was frankly very poor, even in VS2010.
So I figured either the tools would evolve into a profession package or MS would drop it as they do with many good ideas. Looks like they have just sat on it and done nothing so far.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
In the meantime, WinForms (or rather, the common controls) is still one of the most tested and tried user-control set available. They're intuitive, well-known, tested to death and well documented. It is available on every platform that runs Mono, which is quite a lot.
If I am to change a winning formula, there'd better be a good argument or incentive to do so.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: It is available on every platform that runs Mono, which is quite a lot.
Having mono sounds like a disease. 
Once you lose your pride the rest is easy.
In the end, only three things matter: how much you loved, how gently you lived, and how gracefully you let go of things not meant for you. – Buddha
|
|
|
|
|
It's not WPF that attracts me to the methodology, but XAML. The ability to see immediate results for my UI design is mission critical. The code-compile-test-debug-compile-test cycle is a major slowdown. But XAML does have that unfinished feel. Things you would think would be part of the markup system, aren't, it omits standard elements, etc. An example of the last one is the lack of 3D primitives (sphere, torus). And the documentation is quite poor. And of course the solid entanglement with the Microsoft platform that currently exists is what stopped the Mono project from trying to import things over. But given a choice of WinForms vs. XAML? XAML/WPF wins every time (at least on Windows platforms).
|
|
|
|
|
Basketcase Software wrote: The ability to see immediate results for my UI design is mission critical. The
code-compile-test-debug-compile-test cycle is a major slowdown.
So, you can't design a WinForm and see the results without compiling/testing/debugging? How is it mission-critical to see EACH instance of a textbox or button you create?
Basketcase Software wrote: But XAML does have that unfinished feel.
It is not a feeling; compare it to WinForms and it is immature. The XAML-designer ate roughly 20Gb of my harddisk before crashing the IDE. You run into all kinds of crap that has already been solved before.
Basketcase Software wrote: But given a choice of WinForms vs. XAML? XAML/WPF wins every time (at least on
Windows platforms).
No, it doesn't.
Some people/companies/governments prefer recognizable, consistent UI's, and will not pay to have some hardware-accelerated animations and gradients. They'll pay to not have those.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: So, you can't design a WinForm and see the results without compiling/testing/debugging? How is it mission-critical to see EACH instance of a textbox or button you create?
Because it's not just the textbox or button, but its appearance, location, etc. I'm a game UI designer and the aesthetics often matter as much as the function. If you want "plain vanilla" appearance and function then the usual cycle is shortened as there isn't much new - but you aren't being very creative.
Eddy Vluggen wrote: It is not a feeling; compare it to WinForms and it is immature. The XAML-designer ate roughly 20Gb of my harddisk before crashing the IDE. You run into all kinds of crap that has already been solved before.
Agreed. That's the bad thing about Microsoft. They start off with some wonderful technologies that look promising and then just let them die. And of course typically never let them completely mature in the first place. WinForms has had a LOT of developer feedback. For the longest time it was the only game in town and it's what everyone got used to. XAML/WPF comes along and there has been resistance to learning a new paradigm (as if that's a surprise!) even when some things have really needed to be overhauled. A case in point. Even with XAML/WPF I'm presently still stuck with the the standard file load/save/print dialogues - Microsoft (last I knew) never developed versions for the framework. The code is ancient and doesn't seem to grasp asynchronous operations very well. The result? I've seen some weird hangs just saving several image files to a USB drive.
...What on earth were you doing that used 20GB? Hell, I've run XAML on an old XP machine with VS 2010 and a HDD of less the 20GB in size. Never had the IDE crash. I had it give up on some malformed XAML, but never had to go as far what's happened to you.
Eddy Vluggen wrote: No, it doesn't.
For me it does, which is what I meant.
Eddy Vluggen wrote: Some people/companies/governments prefer recognizable, consistent UI's, and will not pay to have some hardware-accelerated animations and gradients. They'll pay to not have those.
Yep, those are the people who have stubbornly stuck to Internet Explorer 6, Windows XP, etc.
If they are willing to pay for it, I'll give it to them. I don't need animations or gradients, but my turnaround time will be much faster producing their simple UI in XAML than doing it using WinForms, and less likely to be buggy and unresponsive either.
|
|
|
|
|
For textboxes and buttons in a WinForm, the location would be rather predictable; games are a class in its own; it will be judged mostly by its graphics, something which would not be my primary concern for, say, Visual Studio or a data-entry application 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
WPF has that nice "Device Independent Pixel" feature that WinForms lack, so location isn't as readily predictable as a developer would like (this was brought elsewhere in these forums: What is the big deal with WPF[^])
Not sure why you included VS in your short list, but a data entry application is somewhere we would agree.
Check out that article link. Found it after my last posting in this thread.
|
|
|
|
|
Basketcase Software wrote: WPF has that nice "Device Independent Pixel" feature that WinForms lack
I never missed it, but it IS fun to read the history of scaling and how we try to negate different resolutions and dimensions.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Abhinav S wrote: why would one switch to WinJS?
Windows Library for JavaScript
Yeah, exactly. Why???
Marc
|
|
|
|
|
I have the impression it is kind of a Microsoft Bootstrap.
Edit:
(There will be probably an API war again)
modified 20-Oct-19 21:02pm.
|
|
|
|
|
You're looking at it from the wrong angle. WinJS was never intended to pull people from the XAML stack; rather, it was introduced to try to persuade JavaScript/web developers to develop apps that would run on the confusingly named WinRT/Metro/insert name here platform. If you are a web developer, the theory is that it makes more sense for you to target WinJS than it does learning C#/XAML (for instance).
|
|
|
|
|
Documentation on WinJS is limited and at first instance it seems rather cumbersome to use.
Imagine they have a namespace concept in JavaScript (sort of neither here nor there)!
Any experience working on WinJS?
|
|
|
|
|
I did evaluate it when it first came out - there was nothing that would make me switch from XAML, but as I have been using XAML a long time, I'm not really part of the target profile.
|
|
|
|
|
I've poked at it a little bit, and it seems more built to interact with a stack back end template than with a actual developer. Just the navigation model is oblique and, as mentioned previously, cumbersome. There's also the fact that several of the hooks in it are for Windows API and not for a browser, which makes its usefulness as web application UX component limited.
I can't recommend it.
|
|
|
|
|
I've looked into using WinJS as a control suite/UI framework for Web Apps, as the most recent version, 4.0, can be run straight out of the browser. In this regard, it looks like a very good competitor.
However, for writing Windows Store Apps, if targeting other platforms is not a concern then XAML wins. XAML/C# is far more elegant than HTML/JS.
As for WinForms, XAML was definitely a step in the right direction and then came along the whole web craze which kind of killed it. Web frameworks are only starting to catch up to the abilities of XAML (check out http://aurelia.io).
modified 23-Jun-15 7:58am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)