Feature update - Multitasking?

[Yellowhorse]

I find that running the Device Monitor and being unable to do anything else while it is open to be severely limiting and to be honest....a little annoying. I can't be the only person that doesn't like not being able to have multiple 'active' windows going at the same time.

I know I'm picking nits here but, I sure would like to see this issue addressed in the next release/update of EScribe.

While I'm here, Kudos to Evolv for the DNA200 and the EScribe software. What a great product!

[Gm111]

I think they would have done this by now if they could, we'll soon find out.. I think you have to close D/M to change settings and then go back onto D/M due to having to have the device in idle too upload settings, when in D/M the device is not idle..

[Yellowhorse]

Gm111 said:

I think they would have done this by now if they could, we'll soon find out.. I think you have to close D/M to change settings and then go back onto D/M due to having to have the device in idle too upload settings, when in D/M the device is not idle..

That's exactly what I'm talking about. EScribe only lets us do one thing at a time. When that Device Monitor is open, you can't open anything else up - even to look at it. I see that as a big problem.
YES, it's 'fixable'. It's just a matter of getting Evolv to do it.

[VapingBad]

Yellowhorse said:

[QUOTE=Gm111]I think they would have done this by now if they could, we'll soon find out.. I think you have to close D/M to change settings and then go back onto D/M due to having to have the device in idle too upload settings, when in D/M the device is not idle..

That's exactly what I'm talking about. EScribe only lets us do one thing at a time. When that Device Monitor is open, you can't open anything else up - even to look at it. I see that as a big problem.
YES, it's 'fixable'. It's just a matter of getting Evolv to do it.[/QUOTE]
You mean you can't use the other parts of Escribe?  That is common practice in software design, modal window, I don't see it is a issue at all YMMV.

[retird]

Since the Device Monitor is monitoring in live time it may be that changes can't be made to the device while Device Monitor is open??  At any rate this request has been asked for before so there may be a reason/reasons it is the way it is I'm guessing.....when in DM it has control of the device thus in the lower right hand corner there are thing you can do like fire the device, chg temp, set power, run diagnostics, and etc.

[Yellowhorse]

dc601 said:

Since the Device Monitor is monitoring in live time it may be that changes can't be made to the device while Device Monitor is open??  At any rate this request has been asked for before so there may be a reason/reasons it is the way it is I'm guessing.....when in DM it has control of the device thus in the lower right hand corner there are thing you can do like fire the device, chg temp, set power, run diagnostics, and etc.

You are completely missing the point. You can't do ANYTHING if the device monitor is running.
EVERYTHING else is disabled. File, Edit, Internet, Options, Tools, Profiles, Help, Atomizer Analyzer, Copy Profile, create a new wire profile - ALL of them are useless if the device monitor is running.
There are plenty of things we could do without 'changing' anything on the device that would require an upload or download to the DNA200 - except.....you can't.
THAT, is what the 'problem' is.

[VapingBad]

So many programs work like this, it is by design and the long established paradigm to use a modal window when operations have the potential of interfering with each other and is used by responsible software engineers to prevent conflicts and bugs occurring.  I just don't understand the problem Device Monitor saves it's settings you only have to close it, do the other thing you wanted and open it again.

[johndoe123]

Just thought I would give an idea here. Device Monitor and the rest of EScrive work completely differently (with regard to hardware). Evolv should make two separate apps. They install together (for Windows) and then you can open one of them or both of them at once.

Why do this? Mac/Linux support!!! This would allow Device Monitor to be implemented on Mac/Linux very quickly as no drivers are needed.

Just a thought...

[Yellowhorse]

VapingBad said:

So many programs work like this, it is by design and the long established paradigm to use a modal window when operations have the potential of interfering with each other and is used by responsible software engineers to prevent conflicts and bugs occurring.  I just don't understand the problem Device Monitor saves it's settings you only have to close it, do the other thing you wanted and open it again.

It sure doesn't look like the Device Monitor is 'saving' anything at all. You can see it slowly reloading the information from the device every time you open it. If it was 'saved', it would snap back open to where it left off when you closed it. It appears to operate in 'real time' only and is not 'cached' at all.

A 'bug' is a defect that is already in the program. One does not 'create' a bug simply by opening another window. I've been an IT Professional for 35 years and would like to think I know a 'design flaw' when I see one. Opening another window to view or do something else should not affect a window that is simply monitoring/reading data from the device. Uploading a new program to the device is a different matter all together and I could understand a suspension of the other functions until the upload is complete but that is not what is happening here. Again, this software does NO multitasking and I see that as a flaw.

While my opinion on how this software 'should' work is my own, it is clear that there is plenty of room for factual/functional improvement. I'm sure that there will be changes/upgrades made to the program as time goes by. I'll be keeping my fingers crossed for the changes to happen sooner rather than later.

Just putting my 2 cents in.
Enjoy your day, everybody.

[Yellowhorse]

smartalec1020 said:

Just thought I would give an idea here. Device Monitor and the rest of EScrive work completely differently (with regard to hardware). Evolv should make two separate apps. They install together (for Windows) and then you can open one of them or both of them at once.

Why do this? Mac/Linux support!!! This would allow Device Monitor to be implemented on Mac/Linux very quickly as no drivers are needed.

Just a thought...

Not a bad idea but I see no reason that the software couldn't be multi-threaded and include all those features in one package. One install....to rule them all.

[VapingBad]

Remember the main window allows reading and writing to the EPROM as dose Device Manager, you don't want to be doing both at the same time.

[retird]

Yellowhorse said:

[QUOTE=dc601]Since the Device Monitor is monitoring in live time it may be that changes can't be made to the device while Device Monitor is open??  At any rate this request has been asked for before so there may be a reason/reasons it is the way it is I'm guessing.....when in DM it has control of the device thus in the lower right hand corner there are thing you can do like fire the device, chg temp, set power, run diagnostics, and etc.

You are completely missing the point. You can't do ANYTHING if the device monitor is running.
EVERYTHING else is disabled. File, Edit, Internet, Options, Tools, Profiles, Help, Atomizer Analyzer, Copy Profile, create a new wire profile - ALL of them are useless if the device monitor is running.
There are plenty of things we could do without 'changing' anything on the device that would require an upload or download to the DNA200 - except.....you can't.
THAT, is what the 'problem' is.


[/QUOTE]

As I attempted to explain:  when in DM it has control of the device thus in the lower right hand corner there are thing you can do like fire the device, chg temp, set power, run diagnostics, and etc.

  One click closes it, do your stuff in EScribe and one click opens DM again.  FYI I asked the same thing during beta testing of the EScribe software (more than once).  I have lots of Windows software whereby you have a screen open to do a task and you cannot access anything else until you complete the screen or close it thus this is not an issue for me but YMMV.

Maybe Evolv's software guru could comment if he has time...

Have a great day yourself...  

[BobC]

As a technology senior executive in the financial community for 35 years, having managed development of applications on platforms ranging from mainframes to smartphones, the use of modal windows are the result of poor software design, not application/hardware requirements, as any restrictions can easily be implemented using resource locking in a multi-threaded environment.

Please understand, Escribe is nothing more then a communications interface built specifically for the win32 graphical user interface, that's the problem, and as I stated before on this forum, the only reason it hasn't been ported to OSX and the mobile Linux environments of Android and IPhone, as that effort requires a re-write of the software.

[VapingBad]

I disagree modal windows ensure users operate the software safely, as it has been tested and as intended to work, important windows going out of view can cause more problems than being forced to operate in a specific way.  I think it would be more frustrating disabling all the functions that read from or write to the device while DM was open and possibly behind the main window, many users would find that confusing and unintuitive.

[BobC]

You're not a developer then, trust me, quality user interface coding doesn't work that way, you don't have to go enabling/disabling all the reads and writes all over the place, those functions should be developed as common modules/components/objects. It only depends how well you program the app, reads and writes can all be blocked calls, with resource locks maintaining resource integrity, it's not a new concept.

Secondly, with the advent of mobile platforms, and decreasing relevance of the traditional desktop/laptop, it was extremely short sighted to implement escribe wired directly to a single operating system, I'm sure I speak for most in wanting an android/Iphone version of escribe if only for setting /reading settings and usage 

[VapingBad]

IMO just because it is possible doesn't mean it is best, I know you can queue and lock after all you would only get one port handle, I am sure you have heard of KISS.  Mobile apps and single page web apps are basically modal windows anyway, this is an app for untrained users from all walks of life that will have vastly different levels of understanding and many would be confused when Attie Analyser worked differently because DM was running or why DM pauses when I click upload setting to device just as two examples.

[BobC]

Actually, if it's programmed correctly, the user wouldn't even notice in most instances with exception to upload, which should cause a freeze on everything due to IO blocking for the load and disconnect from the reboot. Proper programming would enable IPC messaging so processes can listen for the load message and manage user notification and the restart

[retird]

So, if it is programmed correctly?  How much additional programming would be necessary (software and firmware) and how much additional device memory needed? 

A simple click closes DM... do what ya want in EScribe then another simple click and DM is opened again... 

What is the advantage to having DM open and running while doing things in EScribe?  

[BobC]

Nothing additional would be necessary at the device, firmware or hardware, remember, escribe is only a communication interface to the DNA200, with a user interface for value display and editing, we are purely speaking of software development best practices for user interfaces.

As far as an example of an extreme advantage, how about the ability to update atty override value and see the results in real (near real) time

[retird]

All the changes just to avoid a couple clicks.... in your example it would require an upload to the device while DM is running.... still don't see a couple clicks to close/open DM as such a big issue IMO...you see the results in real time (near real) either way...IMO 

[BobC]

not an upload, just a send of the override value, try it on the atomizer analyzer, the results are instant, but you are correct, you can in fact:

1.) open the Atomizer analyzer and change override value
2.) close atomizer window
3.) open Device monitor and view results of the change
4.) Close Device Monitor
5.) open the Atomizer analyzer and fine tune override setting
6.) close atomizer window
7.) open Device monitor and view results of the change

Or you can.................
1.) open the Atomizer analyzer
2.) open Device monitor
3.) move to Atomizer analyzer and adjust setting
4.) see results instantly in the DM window

[black lace]

Been keeping out of it for the past 24 hours, but now understand what theym on about, it would be cool to have dm open, say quater screen in eg top right and be able to make adjustments in main program, allready being able to sit it there but do nothing is barmy, collapsing it down to the bottom tool bar on windows desktop and still not being able to use the main program is even barmier.. i dont honestly think the op is nit picking, this is the 21st century, to be infront you have to be in front, theres a utube vid somewhere, saying they can only copy they can't overtake, is this program side not somthing that could be overtaken on..

[VapingBad]

But AA pulses the coils regularly and DM doesn't so you would have to make 2 distinct modes for AA and then test both, adding override ohms to DM is a good idea though. 

GUIs should be task focused and never just feature packed, they should never divert your focus from the job in hand.

[BobC]

Modes have nothing to do with it, again, escribe does nothing on the chip, it's a pure communications interface with a UI slapped on it, and I'm not sure where your UI best practice is derived from, but it sure isn't anything I've seen subscribed to in my experience, the UI should be geared to (and only to) the user experience, and the diverse needs of all consumers.

Last post on this, I'm speaking to actual development best practices, not layman's theory, YMMV

[Yellowhorse]

BobC said:

As a technology senior executive in the financial community for 35 years, having managed development of applications on platforms ranging from mainframes to smartphones, the use of modal windows are the result of poor software design, not application/hardware requirements, as any restrictions can easily be implemented using resource locking in a multi-threaded environment.

Please understand, Escribe is nothing more then a communications interface built specifically for the win32 graphical user interface, that's the problem, and as I stated before on this forum, the only reason it hasn't been ported to OSX and the mobile Linux environments of Android and IPhone, as that effort requires a re-write of the software.

BINGO!! That's exactly what I've been 'trying' to say.